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ABSTRACT 


Currently, the Navy stores and retains data in multiple data warehouses, in various 
formats, in numerous legaey systems. The Navy’s Bureau of Personnel is responsible for 
four distinet data stores that house unique data for: Aetive Duty Offieers, Aetive Duty 
Enlisted, Drilling Reserve Offieers and Enlisted, and all Inaetive Service members. 
Decision-makers within the Navy have proposed combining the data into one cleansed, 
metadata tagged, indexable and searchable enterprise data environment. This 
environment will resolve redundant storage issues, as well as eliminate outdated, end-of- 
lifecycle equipment and legacy infrastructure. This research will focus on the following. 
Eirst, this research will focus on the current state of IT systems from the Department of 
Defense (DoD) level through the Department of the Navy (DoN) level to the focal 
system—the Reserve Headquarters Support (RHS) system. Second, research of current 
departmental guidance as to the desired state of these systems will be conducted and 
summarized. Third, economic, technical, and strategic management theories will be 
studied and applied in order to conduct an economic analysis of the possibility of 
migrating the RHS application to a more modern IT solution. In the final chapter, 
conclusions and recommendations are provided concerning the most attractive way to 
proceed with the RHS application. Einally, possibilities for follow-on work are discussed. 
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I. INTRODUCTION 


A, PURPOSE 

Research for this thesis will focus on conducting technical, economic and 
personnel implication studies to determine whether the Navy should focus on upgrading 
the current data management function for the Reserve Headquarters Support (RHS) 
Information Technology (IT) application. It will examine the current and desired state of 
information systems—from the Department of Defense (DoD) organization level down to 
the RHS system level. The research will then explore methodologies—including 
technical and managerial methods—best suited to a possible migration of RHS to more 
modem business architecture. Finally, if applicable, the researcher will present 
alternative solutions to meet this objective and will conduct an economic analysis to 
identify the most qualified solution. 

B, BACKGROUND 

Currently, the Navy stores and retains personnel data in multiple databases 
supporting multiple, separate functions in geographically dispersed locations. 
Potentially, the facilities and the data they store could be combined in fewer facilities. 
Additionally, this study will research whether the current system architecture leads to 
logistical issues associated with such storage and if problems exist due to the age of the 
systems that currently perform these functions. Other areas of research include potential 
sources of inefficiencies and unnecessary system redundancies. Further examination of 
these data-storage facilities will be conducted to determine if business best practices such 
as sharing or combining similar functions between organizational entities or throughout 
the enterprise are leveraged. 

Recently problems have surfaced as the Navy shifts towards integration of both 
active and reserve components (AC/RC). These problems have created personnel 
management difficulties not only from an external DoD organization level, but also from 
an internal Department of the Navy (DoN) level. This paper will research whether these 
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problems are caused by, or could be diminished by the application of IT solutions and 
what these solutions might entail. In addition to the potential issues previously mentioned 
(disparate systems, lack of sharing/combining), the component information technology 
infrastructures rely upon antiquated database technologies that were put into production 
in the 1970s and 1980s. Issues associated with systems that are this old will also be 
examined. 

Policy and operational considerations for both AC and RC organizations must be 
researched to identify common ground, as well as disparate factors concerning both of 
these organizations’ policies and operations. The implications of the research within 
these constraints is that combining the organizations’ data solutions may or may not be 
feasible for reasons other than those strictly technical or economic. 

The framework under which this research will be completed will identify current 
operations, procedures, business rules and economics of the existing systems at all levels 
of the DoD. Once the research of the current information systems and desired states has 
been discussed, comparable organizations—either internal or external to the government 
and that have completed projects of a similar size and scope—will be identified for 
benchmarking purposes. In addition, the researcher will review the most current research 
in the field of enterprise architecture to identify common themes that exist in 
organizations that have successfully transitioned their IT systems. These lessons learned 
will be applied to this research, acting as a roadmap for similar DoD and subsidiary IT 
systems and their own efforts for transition. Ultimately, after the research materials are 
examined, the researcher will make recommendations about the future direction of the 
RHS system. 

C. SCOPE 

One of the goals in conducting this study is to determine if the migration of the 
Reserve Headquarters Support application and its associated data is warranted. One 
potential alternative solution is the Defense Integrated Military Human Resource System 
(DIMHRS), which is supported by the DoD through the Business Transformation Agency 
(BTA). Another potential alternative is for migration to the Enterprise Data Environment 
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(EDE)—^which is currently under development at Spaee and Naval Warfare Systems 
Command (SPAWAR) Systems Command, New Orleans (SSC NOEA). To reaeh 
eonelusions and formulate recommendations, the researeher will eonduet an eeonomic 
analysis eomparing the three alternatives (current system, DIMHRS, and EDE) from both 
a cost and benefit perspeetive, ineluding quantitative and qualitative measures. 

A portion of this paper will be technical in nature. However, speeific technieal 
solutions to the owners of RHS will not be rendered. Instead, if and when warranted, 
general guidelines for the sueeessful future positioning of the RHS will be offered. Erom 
an eeonomic standpoint, this study will present researeh to determine the eurrent eosts of 
doing business and what the proposed solutions eosts would be. These eosts will inelude 
investment as well as sustainment eosts. Additionally, the expeeted benefits provided by 
eaeh of the alternatives will be examined. The eost estimates of proposed solutions 
within this paper are not meant to be exaet, but they are provided in order to make a 
eomparison possible by using best estimates based on eurrent information. In addition, 
the researeh eondueted will break down the teehnieal and eeonomie aspeets of the foeus 
system (RHS) to a level that would ensure reasonable projeetions for future development 
efforts and eosts. 

Additional value of this study exists in the possibility that other military 
organizations looking to do similar work might leverage the work eompleted in this 
thesis. This researeh will not aim to provide aetual teehnieal solutions; it will, however, 
render a high-level assessment of the teehnieal feasibility neeessary to meet the stated 
requirements. Eurther, this assessment eould provide a starting point for further researeh 
into teehnology-speeific solutions for migrating RHS from its eurrent state to a desired 
state. Eeonomieally, an analysis of eurrent eosts to operate and maintain the RHS 
applieation ean provide a reasonable representation of the eurrent state (as this is a known 
quantity and a matter of aceounting). However, the foreeasting of costs will be limited to 
those faetors that ean be estimated without a speeific technology solution in mind. 
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D, METHODOLOGY 


The research methods used in this paper consisted of interviewing system owners 
and stakeholders, reading topic related literature (both academic and professional), and 
applying concepts that the author has learned through formal education and industry 
related experience. A preponderance of the data enabling the research for Chapters II and 
III of this thesis was collected from SSC NOLA, Commander Navy Reserve Forces 
Command (CNRFC), the Navy Program Executive Office for Enterprise Information 
Systems (PEO EIS), and the Navy Manpower Personnel Training and Education (MPTE) 
organizations. Chapter IV references material that was more scholarly and guidance- 
oriented—including works by industry experts and academics working in the area of 
software and enterprise architectures. Other useful resources for this research included; 
lectures attended at the Naval Postgraduate School, various Internet sites, and discussions 
held with professors and the researcher’s Thesis Team. Einally, additional data was 
gathered from multiple other resources relevant to the focal organizations and subject at a 
level appropriate to the scope of this thesis. 

The researcher used multiple research methods to collect data for this study— 
including interviews with the CNREC and SSC NOLA staff. Additionally, interviews 
and one-on-one discussions with professors were used to gain direction as to where data 
pertinent to this topic could be attained. Once these sources of data were discovered, the 
researcher accumulated and researched all the available secondary data regarding the 
support of RHS. Thus, the research conducted in the completion of this thesis was 
secondary in nature. All sources cited in the study were researched for validity and 
accuracy before being cited. 

This remainder of this paper is organized as follows. Eirst, in Chapter II, the 
current state of IT systems at all levels of the DoD is examined down to the RHS level. 
Second, based upon a study of the existing literature. Chapter III examines the desired 
state of these same systems. In Chapter IV, methods for bridging the gap between the 
current state and the desired end-state are examined including a relevant economic 
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analysis. Finally, based upon the preeeding ehapters, eonelusions, reeommendations and 
answers to the primary and seeondary questions posed by this research are given. These 
research questions are as follows. 

Primary research question: 

What are the implications of migrating from the Navy’s current disparate data 
warehousing architecture to an integrated solution with a focus on the Reserve 
Headquarters Support (RHS)? 

Subsidiary research questions: 

What is the cost of the current data warehouse solution; how much would it cost 
to upgrade, and what cost model can be used to appropriately forecast the cost the 
upgrade? 

What is the current technical architecture that supports data warehousing of the 
Navy’s data, and is it appropriate? 

How would migration of the RHS be carried out from a technical standpoint? 
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II. CURRENT STATE OF INFORMATION SYSTEMS 


A, DEPARTMENT OF DEFENSE (DOD) 

The Department of Defense (DoD) is a massive organization that has operated in 
a highly dynamie environment for many years; one bi-product of that situation is that the 
DoD’s financial and manpower information stores are highly partitioned or siloed along 
Military Active Component (AC) and Reserve Component (RC) lines, as well as between 
military and civilian government organizations. This structure has forced the separate 
organizations to create infrastructure to support themselves separately. This separation 
has made it difficult to share information among the components of the DoD—a problem 
glaringly evident in issues with personnel assignment during Operation Iraqi Freedom 
(OIF) and Operation Enduring Freedom (OEF). Additionally, separate staffs and 
facilities have been created and continue to operate in their component-specific 
environments. 

The creation of the Business Transformation Agency (BTA) in 2006 was the 
DoD’s response to remedy this situation. The BTA has mandated that all organizations 
within the DoD work toward the creation and sustainment of an enterprise architecture. 
Of particular interest to this study is the development and deployment of the Defense 
Integrated Military Human Resource System (DIMHRS), which is to replace all of the 
personnel systems currently in use within the DoD (military and civilian). Of course, this 
will be phased into production over a period of several years—with the Army scheduled 
to be the first organization to go live with the DIMHRS. Per the Army DIMHRS Web 
site, the implementation date of March 1, 2009, was postponed. In fact, the whole 
program has been suspended until further notice (US Army PEO EIS, 2009). 

However, the fact remains that the DoD is moving towards integration of its IT 
systems; what form that transformation takes remains to be seen. What is important to 
this study is the fact that support exists at the highest levels of our government to ensure 
the technology it possesses within its organizations is capable of meeting the missions of 
the future. 
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B, DEPARTMENT OF THE NAVY (DON) 


The Navy currently stores and retains its data in multiple data warehouses, in 
various data element formats, in many disparate legacy systems. The Navy’s Bureau of 
Personnel is responsible for five distinct applications that track, store and manipulate data 
for Active Duty Officers, Active Duty Enlisted, Drilling Reserve Officers and Enlisted, 
and all Inactive Service members. These applications are authoritative data sources 
(ADS), which are “a designated, or agreed upon, trusted source of information” (US 
Army CIO, 2009). These applications support and interface with several organizations’ 
systems—both internal (such as recruiting systems) and external to the Navy (such as the 
Defense Einance and Accounting System (DEAS), which, among other services, is the 
military pay system). “Per the DIMHRS Milestone B Operational Requirements 
Document, there are five Navy personnel systems that are subsumed by DIMHRS” (ASN 
(M&RA), 2009, p. 7). 

• Navy Enlisted System (NES) 

• Officer Personnel Information System (OPINS) 

• Navy Standard Integrated Personnel System (NSIPS) 

• Reserve Headquarters Support (RHS) 

• Inactive Manpower and Personnel Management Information System 

(IMAPMIS) 

The DIMHRS only covers personnel- and pay-related functionality. Therefore, 
although the bulk of these systems’ functionality will be covered by the DIMHRS, they 
do have some non-personnel-related functions that will be maintained separately. In the 
next section, we examine the specific interfaces these five applications have within the 
Navy Manpower, Personnel, Training and Education (MPTE) environment. 

1, Manpower, Personnel Training & Education (MPTE) IT 

According to the Navy Total Force (NTF) team, “The MPTE domain was 
officially created in July 2005 by the merger of the Manpower and Personnel with 
Training and Education commands” (NTF, 2009, p.l). This move was made in an effort 
to ensure that operations undertaken by the Navy are supported in the most efficient 
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manner possible utilizing the Total Foree (all personnel in either aetive or reserve status). 
Due to this organizational restrueturing, all of the IT assets of the merging entities have 
been plaeed under the purview of the Deputy Chief of Naval Operations (Manpower, 
Personnel, Training & Edueation). With this eombination, the IT system has beeome 
more eomplex due to the greater size and inereased funetionality housed within one 
system. However, this eombination plaees all of the authoritative data sourees of the 
Navy under the direet eontrol of one organization, whieh should aid in aehieving the 
goals of the DoN and DoD of enterprise alignment of IT systems. 

a. Issues in the Environment 

The focus system of this study, RHS, lies within the MPTE IT domain, 
which is predominately concerned with the management of all Navy personnel and all 
functions associated with human resource management. As discussed previously, five 
separate systems make up the personnel authoritative sources portion of the MPTE IT 
System; NES, OPINS, NSIPS, RHS, and IMAPMIS. Actually, NSIPS is a record-entry 
application used to interface with the other four systems; thus, the remaining four systems 
comprise the entire authoritative data sources concerning personnel, as depicted in Eigure 
1 . 
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Figure 1. Navy Authoritative Data Sourees for Personnel (From Aries Systems 

International, Inc., 2005) 


In this section, we will focus on some of the issues associated with the 
MPTE system environment, in particular; 

• Age of the technology (both hardware and software), 

• Number of associated interfaces with these systems, 

• System maintenance, and 

• System complexity. 

(1) Age of the Technology. A document retrieved from the 
DoN Website entitled “Draft DON DIMHRS Concurrent Review” concerning the age of 
the MPTE system components states, “All of these systems, except NSIPS, have been in 
sustainment mode since mid-1970. Only congressionally mandated improvements and 
functional maintenance have been done on the systems” (ASN (M&RA), 2009, p. 7). 
This fact presents myriad associated problems, including dated hardware, dated software, 
overburdened and inefficient architecture, lack of qualified technicians, and necessarily 
inefficient procedures. 
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If Moore’s Law is applied—^whieh states that the number of 
transistors that ean be plaeed on a ehip doubles roughly every two years—and assuming 
an average in-serviee system date of 1979, then the four authoritative data souree systems 
are about fifteen generations behind the latest teehnology. Further, aeeording to Kanellos 
(2005), this trend “will eontinue for at least a deeade” (p. 1). Thus, if not ehanged prior to 
2015, these systems will be eighteen full generations behind the latest technology. Given 
the pace with which the DIMHRS has progressed, this possibility seems to be highly 
likely. This scenario—combined with the issues associated with the DoD acquisition 
process of large-scale IT systems—does not bode well for the replacement of these 
systems anytime in the very near future. 

(2) Number of Interfaces, According to the DoN Program 
Executive Office (PEO) Enterprise Information Systems (EIS), there are hundreds of 
interfaces among the systems focused on in this paper, with many of them sharing 
multiple files. These files are shown in the following figure (Murphy, 2007). As one can 
see from the graph, the RHS alone has over 75 interface files, which we will inspect in 
the following section. 


NifTberof liteiface/bterlaoeFie Per System 



Eigure 2. Number of Interfaces/Interface Files per System 
(From Murphy, 2007, Slide 47) 
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Over the years, the number of interfaees has eontinued to grow as 
new systems are added within the enterprise, whieh in turn require connections to the 
MPTE domain. This trend will likely continue. As the number of system interfaces 
increases, the performance of a system is degraded. This is due to several factors, 
including: 

• The overall system complexity increases as more systems are added. 

• Each interface requires system hand-offs at the software level, 
necessitating communication between systems via protocols, thus taking 
processor time. 

• Hardware components are constrained, as they are utilized more heavily 
and frequently. 

In addition to these issues, advances in hardware have outpaced 
those made in software. This can be attributed to many factors—including the fact that 
software is more complex, as it is based upon logical properties rather than physical 
factors that dictate hardware development (Osmundson, 2009). 

(3) System Maintenance (Ad-hoc Eixes to Interface Issues). The 
issues just discussed of old technology and multiple interfaces greatly increase the 
complexities of system maintenance. Aside from the purely technical issues, the 
personnel problems associated with these older systems are complex. Most IT 
professionals trained today are not being trained in the technologies used in the 1970s. 
Additionally, the aging information systems are mirrored by an aging workforce who are 
not trained in the latest technologies and have a high attrition rate. Einally, many people 
have moved on to different careers, to different parts of the organization, or have simply 
retired—creating a serious threat of not having enough qualified people to work on these 
systems. 

(4) Data Issues (Quality, Synchronization, Maintenance). Within 
the MPTE IT domain, there are several issues related to the data that it uses, owns, and 
creates. Of these issues, those associated with quality, synchronization, and maintenance 
are focused on here. Each of these issues is distinct in the problems it presents; however. 
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each issue is intertwined and cannot be separated and fixed in isolation. If data quality 
and synchronization issues are addressed, it logically follows that maintenance problems 
will be diminished. 


Data Requirements 

DoD I Legislative/ Operational / Analytical 



PRIDE IMAPIVIfS 

CNRC Pers -9 


NES 

Pet^-3 


OPIMS 

Pers-3 

Pers-B 


RHS CeTARS 

CNRF NETC 



Figure 3. Current MPTE Data Management Environment 

(From Pavelec, 2008, p. 3) 


Figure 3 illustrates some of the issues associated with the current 
data architecture of the MPTE domain. Per the Data Management and Integration (DMI) 
Roadmap: 

[T]he MPTE enterprise currently relies on “siloed” systems within fragmented 
organizations. Because of the isolation of data within outdated architecture, there 
are inconsistent data standardization and formatting, inconsistencies with data 
quality, multiple costly interfaces, and nonexistent overarching enterprise data 
governance. (Pavelec, 2008, p. 3) 

If we examine the issue another way, we see the following data- 
related issues within the current environment: 

• Poor data quality—inconsistencies exist in the current environment related 
to data availability, relevance, action-ability, consistency, validity, and 
trustworthiness. 

• Poor data interoperability—this exists between the multiple system 
interfaces; data re-use is difficult due to a lack of common standards. 
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• Difficult maintenance of data—this is related to the previously deseribed 
issues with quality and maintenanee and is exacerbated by the laek of 
enterprise data governance. 

(5) System Complexity. Figure 4 portrays the complexity of the 
MPTE IT environment. In this diagram, a picture is painted of many of the problems 
highlighted in this paper: siloed databases/funetionality, too many interfaces, and 
complexity, to name a few. What this pieture does not eapture is the actual complexity of 
the system, as it is a great simplification of the MPTE IT environment. The actual real 
eomplexities and problems stem from sueh things as system reaeh-baeks (which allow 
necessary system interfaces to be maintained that are not included in new development 
efforts), poor system doeumentation, and an overall lack of understanding of and about 
the system. It is probable that no one person fully understands the entire system or what 
it does. Each person associated with it may understand his or her own small piece, but 
may have little appreeiation for how the entire system works. 
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Figure 4. MPTE System Overview (From Aries Systems International, Inc., 2005) 

No one could understand such a complex system. This lack of 
understanding leads to problems—downstream issues are created when an upstream 
system changes. Often, the upstream system can adversely affect the downstream system 
without knowing it; the upstream personnel might not even know that the downstream 
system exists. This type of problem can even create an environment in which easy 
changes can become highly complex and may even be avoided so as to not cause 
problems for other systems. Decision-makers may implement critical changes without 
notifying interfaced systems, thus creating a ripple effect of errors. If policy-makers do 
not address these issues, the associated system problems will continue to grow and will 
eventually create serious trouble. 
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2, Map of Current Environment 


The next seetion examines the eomponents of Figure 4. In this diagram displays 
several shapes, lines, arrows, eolors, and aetors, as well as a large, light blue oval that 
surrounds a tan oval. Anything inside the tan oval deseribes or depiets the eomponents 
that make up the MPTE environment (many of whieh have been diseussed in this 
projeet). The light blue oval surrounding the tan represents systems that are direet 
external interfaees to the MPTE system. Outside of that are systems with whieh the 
MPTE system interfaees through its direet external links. 

The basic scheme of this picture inside the large, tan oval is that the different- 
colored ovals depict the functional domains within the overall system. Eunctional 
domains are closely related to business functions; each domain performs a function 
related to its pertinent business or operational function. In fact, there may be more than 
one oval of the same color that is intertwined. In either case, the name of the functional 
domain is contained within one of the imbedded blue ovals. Each of the multi-colored 
domain ovals (or clusters of ovals) contains one and only one blue oval. Therefore, we 
can breakdown the MPTE system into its functional areas as follows: 

• Archives—This system stores official Navy personnel files electronically. 

• Personnel (Eield Entry)—These systems are used by authorized users to 
edit, update, and delete information pertaining to Navy personnel. 

• Personnel (Data Repository)—This system stores personnel 

information/data so it can be maintained, retrieved from, and written to. 

• Distribution (Detailing and Assignment)—This domain enables authorized 
users to manage human resource assets in regards to duty assignments. 

• Recruiting—This system tracks applicants who are in the process of 
joining the Navy. Once affiliated, these records form the base of Navy 
personnel records. 

• Education—This system tracks scheduled, formal education and other 
educational pursuits completed by Navy personnel. 

• Training (Authoritative Sources)—This system tracks scheduled and 
completed training by Navy personnel at the individual and unit level. 

• Eiscal—This system tracks all budget-related items for the Navy. 
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• Manpower (Authoritative Souree)—This system is supported by the Total 
Force Manpower Management System (TFMMS) that “provides 
capabilities for storage and retrieval of historical, current, budget, and out- 
year manpower data. It also provides access to current manpower data for 
resource sponsors, claimant, etc.” (CNP, 2009, p. 1) 

• Navy Personnel Research, Studies, and Technology (NPRST)—this 
system conducts research and studies and applies technology to solve 
Human Resource (HR)-related problems. (NPRST, 2009) 

• Personnel (Authoritative Sources)—This system provides manpower, 
personnel and pay management support. 

This breakdown is further illustrated in Figure 5. 
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Figure 5. Navy Functional Business Domains (From SSC NOLA, 2008, Slide 4) 


Within each of the functional areas (depicted in Figure 5) are silver rectangles 
containing acronyms. These are the applications that support the parent function. Many 
of these applications are represented in Figure 5 as they relate to their functional 
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domains. Additionally, arrows extend from and point to the different funetional domains, 
representing the interface relationships. These arrows may have boxes on them that 
describe the basic types of information that is flowing over these interfaces. Finally, 
actors, in the shape of people at their desks in Figure 4, represent the users of the system. 
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Figure 6. Navy Authoritative Data Sources for Training 
(From Aries Systems International, Inc., 2005) 

The preceding figure is used to illustrate a small portion of the system 
flow. The two functional domains depicted are the Personnel-Authoritative Sources and 
Training-Authoritative Sources. One key point is illustrated by the two blue arrows 
pointing from the Personnel domain to the Training domain and the boxes superimposed 


18 























































over them. Here, there are two different colored arrows. These arrow colors match the 
application rectangles borders from which they are coming. In this example, information 
from both the IMAPMIS application and the RHS application (both in the Personnel 
domain) is being transferred to the CeTARS application within the Training domain. 

The basic symbols in the illustration above depict what types of information flow 
through the MPTE system and the complexity of the environment. 

Now, armed with a general understanding of the MPTE IT environment, we will 
focus our attention to one of the applications within the Personnel-Authoritative Sources 
functional domain, the Reserve Headquarters Support (RHS). 

C. RESERVE HEADQUARTERS SUPPORT (RHS) 

Per the Department of the Navy (DoN) Program Executive Office (PEO)- 
Enterprise Information Systems (EIS), the “Reserve Headquarters Support (RHS) is a 
CNREC mission-critical system used in the data collection and dissemination process 
necessary for command and control of SEERES Mobilization” (as cited in Murphy, 2007, 
Slide 30). 

Although the above definition gives an idea about what RHS does, it does not 
explain the system’s mission completely. This section will take an in-depth look at the 
RHS application by describing its functionality, environment, interfaces, and architecture. 
After the system has been described, this project will examine the issues the system faces 
in regards to the aforementioned features. 

1. Functionality 

At a high level, the RHS “provides automated storage, maintenance/update, 
reporting (e.g., accounting, management, and strength), distribution of manpower and 
personnel information, recall/mobilization status, and drill pay on all drilling reserve 
Navy personnel” (JR&IO, 2004, p. 10). As described earlier in the discussion of the 
MPTE environment, the RHS lies within the functional domain of Personnel- 
Authoritative source. This means that the RHS, from the Navy perspective, is the one- 
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stop shop for all Reserve personnel-related information. Therefore, any other system— 
internal or external to the MPTE IT environment—that requires information on Navy 
Reserve personnel needs to interfaee with the RHS to obtain sueh information. This 
aeeess is eritieal to the military, espeeially as the trend towards joint military operations 
eontinues. In the future, the RHS needs to be open to not only Navy systems, but to all 
Department of Defense systems that need information eoneerning Navy Reserve 
personnel. The ehallenge here lies in the faet that the eurrent RHS arehiteeture is not set 
up to serve this purpose but will need to ehange to serve this funetion. 

2. Whom It Supports 

As previously stated, the RHS is the authoritative data souree for the Navy 
Reserve Foree; as sueh, it is “the eentral data proeessing point between 265 Navy 
Reserve field aetivities and all Navy and DoD pay/personnel systems” (Murphy, 2007, 
slide 30). Further, the applieation “supports 57,000 Seleeted Reservists” (2007, slide 30). 
The implieations of these faets is that to leverage the personnel assets of the Navy 
Reserve, outside systems must interfaee with the RHS, and the RHS must be set up to 
reeiproeate. Although today, the aetive duty Navy personnel, as well as the other 
Serviees, are utilizing Navy Reserve personnel assets as traeked by the RHS. This is not 
due to the funetionality of the RHS. Many times these assets are utilized in spite of or 
without the use of the RHS. What has been diseovered is that even within the Navy, it is 
not possible for applieations to leverage the information of other applieations within the 
MPTE environment due to ineompatible arehiteetures and data struetures, as well as other 
problems. In the future, the RHS needs the funetionality to not only seamlessly interfaee 
with internal MPTE applieations, but to also interaet with other organizations external to 
MPTE. This will allow, for instanee, an undermanned U.S. Army unit that is eondueting 
a eritieal operation to aeeess the deseription of a Navy Reserve person that may be a 
mateh for its needs. However, the RHS as it exists today does not eontain this type of 
funetionality. In the next seetion, we will explore the eurrent RHS arehiteeture, its 
environment and the interfaees that the system maintains. 
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3, Map of the Technical Environment/Architecture 


Figure 7 depicts the RHS operational environment. It gives a breakdown at a 
more granular level than the MPTE system overview described in the MPTE section. 
Additionally, it filters out any of the functional areas and interfaces that do not directly 
affect the RHS. What is shown in Eigure 7 is that the RHS interfaces directly with 15 
other applications—either providing information to them, extracting information from 
them, or both. A detailed breakdown of these interfaces follows this section. Here, the 
figure is given to create a visual representation of the RHS to enhance the readers’ 
understanding of the application. In conjunction with Eigure 4, Eigure 7 allows one to 
visually investigate the RHS application level while keeping in mind the overall system 
picture. 
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Eigure 7. The Reserve Headquarters Support System (Erom Bergeron, 2008, slide 5) 
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Based upon information gathered from the RHS system owners at SSC NOLA 
and the RHS System Overview presentation given by the Program Manager, Mr. Kelly 
Bergeron (2008), the RHS application leverages the following hardware and software: 

Platform: HP AlphaServer ES40 Cluster 

Operating System: Open VMS 

Application SAV: VAX BASIC, SmartStar, SQL, DCL 

Database Management System: Oracle 9.2.0.8.0 

The physical location for these assets is currently the SPAWAR Systems Center 
New Orleans (SSC NOLA), with a co-operating site in San Diego, CA. 

Combined, these assets support roughly 290 interactive users and 400-plus Navy 
Lchelon-five-level batch accounts through the Navy Standard Integrated Personnel 
System (NSIPS). Echelon five refers to the level in the Navy organization at which these 
transactions take place; i.e., they take place five layers down from the top. In total, 69 
million transactions are conducted and handled per month on the RHS application. 

As stated above, the RHS application hardware and software is physically located 
and maintained in New Orleans, LA, at SSC NOLA. Ligure 8 gives a view of the logical 
flow of data from the RHS to the Navy Personnel database (NPDB), which is located in 
Mechanicsburg, PA. 
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As depicted in the NOLA box in Figure 8, NSIPS (which is a PeopleSoft-based 
application) provides both database functionality and serves as the front-end interface for 
data input. Through its interface to the RHS, it is used to conduct pay and personnel 
actions for Navy Reserve personnel (JR&IO, 2004). NSIPS is used in the field by 
personnel professionals at Navy Reserve Activities (NRA) and Navy Operational Support 
Centers (NOSC)/formerly Naval Reserve Centers. Additionally, “At the corporate level, 
Navy Personnel Data Base (NPDB), OPINS, NFS, IMAPMIS, RFIS, and Navy Military 
Personnel Data System (NMPDS) provide manpower, personnel and pay management 
support” (JR&IO, 2004, p. 9). NPDB is the integrator database for all Navy personnel 
(active and inactive); however, the data stored in NPDB is limited and does not contain 
exhaustive personnel information for each personnel account. Finally, as the process 
exists today, “Reserve management information is provided via data transfer or hard copy 
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reports to Reserve field aetivities, Reserve Headquarters, SUPERS, Chief of Naval 
Personnel, Seeretary of the Navy (SECNAV), OSD, and other DoD aetivities” (JR&IO, 
2004, p. 10). 

4, RHS Interfaces 

The RHS eontains 15 interfaees and proeesses over 750,000 transaetions per 
month from Navy Reserve field aetivities—ineluding over 300,000 pay transaetions that 
provide $35 million a month in reserve pay (Murphy, 2007). 

The following list highlights a few of the more important system interfaees and 
their funetions: 

• NSIPS, IMAPMIS and DJMS-RC—personnel and pay 

• TEMMS—manpower requirements data, reserve billet data, and 
headquarters-level support for foree billet and mobilization management 

• NSIPS—Three daily transmissions and feedbaek 

• DJMS-RC—Daily transmissions of direet pay data 

• IMAPMIS—Daily pay and personnel data that require Navy eorporate 
system interfaee affeeting transmissions being fed baek to the RHS and on 
to DJMS-RC. 

• RSTARS-HP—Supports DJMS-RC pay proeessing interfaees for Health 
Professions Seholarship partieipants via Reserve Standard Training 
Administration and Readiness Support for Health Professions (RSTARS- 
HP) (JR&IO, 2004, p. II). 

Einally, Table 1 provides an exhaustive list of RHS interfaees, ineluding data flow 
direetion, interfaee type, and purpose of the interfaee. 
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Table 1. RHS Interfaces (After Bergeron, 2008, slide 3) 


INTERFACES: 






SSC NOLA SYSTEMS 







Data flow 

System Name 

Interface Tspe 

Purpose 

To 

OPAS 

FTP Batch 

Resers'e OflScer data 

To 

NTRS 

FTP Batch 

Reserve Perscwne! data 

To From 

TFMMS 

FTP Batch 

BiDet requirements 

To From 

RSTARS (HP) 

FTP Batch 

Student PERS PAY data 

To 

MRRS 

SQLNET 

Reserve Personnel data 

To From 

RIMS(FM) 

FTP Batch 

Reserv e Bonus data 

To From 

NROWS 

SQLNET and FTP 

Reserve Pets and Order data 

To From 

IMAPMIS 

FTP Batch 

Reserve Pers and Pay data (inc. IRR) 

To 

C.MS 

FTP Batch 

Reserve Personnel data 





External Systems 


Data flow 

System Name 

Purpose 


ToFrom 

DJMS-RC 

FTP Batch 

Reserve Pers and Pay data 

From 

DJMS-CL 

FTP Batch 

Reserve Pers and Pay data 

ToFrom 

NSIPS 

SgiNTT and FTP 

Reserve Pers and Pay data 

To 

NMCMPS 

FTP Ffle Batch 

Resenre Pers and Mob data 

To 

CNTIF Staging 

FTP 

Pers Bfflet Mob L'nit data 

To 

CNRF N6 Data Warehouse 

FTP 

Pers Billet Mob Unit data 


For more details on the RHS application, including system statistics, interface 
statistics, and interface descriptions, see Appendix A. 

5, Issues with the Current System 

When the Cost Governance Model was completed by SSC NOLA staff in 
February of 2008, an ominous tone was set concerning the RHS application. According 
to the study, the RHS is at risk of being shutdown due to non-compliance with DoD and 
DoN Information Assurance requirements; a technical re-engineering must be completed 
within the next couple of years. Additionally, this study asserted that the RHS system is 
in jeopardy of a complete system failure due to age-related issues—such as the inability 
to get replacement hardware parts, the aging of the software, and the lack of experienced 
people to work on it (Robertson, 2008), The issues facing the RHS are complex. Thus, 
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the focus of this section will be on issues concerning the system’s underlying technology 
(including interfaces and processes), system support, architecture, and budgetary 
constraints. 


6. Technology 

In a Statement of Objectives document completed by the MPTE code N16 (Chief 
Information Officer), an Enterprise Data Environment (EDE) proof of concept pilot 
program is proposed (Navy MPTE, 2008). Within that document, requirements are 
described that must be met to ensure that migration to an EDE can be met. By reading 
these system requirements, one can see that some deficiencies within the current MPTE 
environment create issues for such a migration. In particular, some of these deficiencies 
can be attributed to the RHS itself Some of these issues or deficiencies include; 

• Identification of authoritative data has not been completed. This issue 
needs to be addressed regardless of whether the RHS application is re¬ 
written. 

• Non-authoritative data has not been eliminated. This issue is related to the 
prior issue in that, once authoritative data is identified, by default, non- 
authoritative data is also identified. This issue is critical to address so that 
unnecessary data is not included in restructuring efforts and so that 
inefficiencies associated with storing, maintaining, and processing such 
data are eliminated. 

• System documentation has not been kept up-to-date. This leads to several 
issues, including a lack of understanding of the current environment and 
an inability to trace its structure and functionality. 

• Domain mission-critical processes have not been identified. Just as with 
the lack-of-documentation issue, without clear delineation of what the 
critical system functions are, change potential is limited. 

• Data dictionary artifacts have not been identified. To understand how to 
improve the system, system owners must understand what the critical 
processes are and then identify the critical data that supports these 
processes. At the time of this writing, the author had made unsuccessful 
attempts to acquire a copy of system data dictionaries from the RHS 
system owners. 

• Supporting system data elements have not been identified. This issue is 
associated with the multiple system interfaces that are maintained within 
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the RHS. If system owners do not have a elear understanding and 
doeumentation of system-to-system dependeneies, data errors will 
continue when changes are made to either the RHS or interfaced systems. 

• A defined change process has not been designed. As system owners do 
not clearly understand system dependencies, at present it is difficult (at 
best) for system designers to put in place any process that will coordinate 
changes among interfacing systems. This limitation creates an 
environment in which changes are made and placed into production. When 
problems arise, there are several possible courses of action: a successful 
firelight ensues that either repairs the interface, or the change is required 
to be backed out, or the system is reverted to its original state. 

As discussed so far, the issues pointed out are of both a technical and procedural 
nature. Now, we will examine some of the specific technical challenges the RHS faces. 

7. Interfaces 

As with many major systems, the RHS system is composed of interfaces between 
systems that have different data structures. This complexity allows for mutually 
beneficial relationships for the associated business system owners and is necessary to 
conduct business and to comply with applicable regulations, among other benefits. The 
issue at hand is not in removing interfaces, which would have the effect of removing 
functionality and/or putting the system in a state of non-compliance; instead, the issue is 
that the RHS does not have the basic building blocks in place for it to continue 
conducting business long into the future. Many of the above-discussed problems are 
impacted by or impact the RHS. Namely, the data quality within the RHS is not as high 
it needs to be, nor are the processes and procedures for interfacing with other systems 
clean and clear enough. 

8. Work-around Processing 

Over the years, complex work-around logic has been built into the RHS so it can 
continue conducting business as usual. These business continuation processes have been 
necessitated by changes to the RHS and changes to the systems with which it interfaces. 
These changes include things such as the ability to accept new file formats from other 
systems, to create custom files that will be useable by receiving systems, and to deal with 


27 



new security requirements. Much of the logic built into the application is complex and 
poorly documented. This poor documentation creates enormous risk for the health of the 
system going forward. If the programmers associated with many of these changes were 
to leave, support of the as-is system would become more complex. This problem is 
compounded by the fact that documentation is inadequate to be of use to any new 
programmers. However, since the RHS is confined to the constructs under which it was 
initially built, the problem of work-around process will be with the system until major re¬ 
engineering efforts begin. 

9. Support 

Production support for the RHS is becoming increasingly complex for many of 
the reasons already stated. Most of these support issues are due to the age of the system, 
the structure (architecture), the number of interfaces, and poor documentation. 
According to Captain Bill Carney, Commander Navy Reserve Forces Command 
(CNRFC) Deputy Chief Information Officer (N6a) (B. Carney, personal communication, 
December 17, 2008), and Kelly Bergeron, SSC NOLA RHS Technical Lead (K. 
Bergeron, personal communication, December 18, 2008), the key areas of concern 
regarding the support of the RHS are: maintenance, upgradability and system 
performance. These are common difficulties in systems as old as RHS. These experts 
further described how, over its lifetime, the application has incurred several 
modifications that have adversely affected performance, reliability, and accuracy. 
Additionally, the architecture is cluttered with excessive interfaces to other systems (each 
requiring code to be written and maintained) that have created difficulties in documenting 
the current state of the system. Adding to the system difficulties is the fact that many 
changes have been made hastily without proper documentation by the technicians who 
maintain them. Therefore, in the future, changes to the system will require extensive 
system experience due to its complexity and lack of documentation. This leads to 
another problem: a lack of trained professionals (both at SSC NOLA and in the IT 
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industry at large) familiar with the older teehnologies upon whieh the RHS is built. In 
addition to the aforementioned support issues, the RHS suffers from funding issues that 
we will investigate next. 

10, Cost/Funding/Acquisition Issues 

One of the eentral issues concerning funding is that the RHS has only been funded 
at the Operations and Maintenance (OM&N) level for the past several years. The 
application has received no Research and Development (R&D) funding with which to 
improve its underlying architecture and explore feasible long-term solutions. 
Additionally, RDT&E funding has been put on hold until decision-makers resolve the 
Defense Integrated Military Human Resource System (DIMHRS). Also, OM&N funds 
have been at the minimum level to run the business for the past several years; only 
mission-critical functions are being supported. The following table—taken from the 
POM 10 PEO EIS briefing (Murphy, 2007)—shows the funding status of the RHS. 
Interestingly, for EY08 and EY09, only OM&N funding was approved for system 
support. However, this problem has been addressed in that for EY 10 through EY 13, 
both OM&N and RDT&E funding have been proposed for budget approval. The addition 
of RDT&E funding is to position RHS to be ready for migration to the DIMHRS. Tying 
the RDT&E funds to the migration effort creates an issue if the DIMHRS is not 
successful. These funds need to be approved regardless of what platform the RHS will 
eventually migrate to because if they are not, the problems that we have described in this 
chapter will only get worse. 


Table 2. Eunding for the RHS (Erom Murphy, 2007, slide 30) 
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RHS is not the only system that is experieneing aeeelerating problems. We will 
now turn our attention to some of the other systems that are faeing similar issues that 
need to be fixed for an eventual move to a more seamless Navy enterprise IT 
environment. 

11. Other Systems to Keep in Mind 

If ehanges to the RHS are to be sueeessful, at minimum those applieations within 
its funetional area (Personnel-Authoritative Forees) must be studied to ensure that they 
will not only eontinue to operate together, but also will offer more robust funetionality 
going forward. Agreed-upon standards will need to be eommunieated and met so the 
RHS will be able to seamlessly transition to the new state without disrupting its 
interfaees. Ultimately, the other applieations within this funetional domain—^Navy 
Enlisted System (NES), Offieer Personnel Information System (OPINS), Navy Standard 
Integrated Personnel System (NSIPS), and Inaetive Manpower and Personnel 
Management Information System (IMAPMIS)—will need to undergo ehanges similar to 
the RHS to ensure future eompatibility and greater funetionality. 

The following points taken direetly from the POM 10 PEO EIS briefing (Murphy, 
2007) highlight some of the issues faeing the aforementioned systems and the assoeiated 
eonsequenees of not proaetively addressing them. Eor elarity, PERSYS is eomprised of 
NES, OPINS and NSIPS, as well as other smaller systems. 

• Operational Risk (High): PERSYS has NO “in-Core” funding in EYIO and 
beyond. If the systems are shut down beeause of a laek of funding, Aetive 
Duty Navy personnel pay will be severely impaeted, and the Navy will not 
be able to effeetively manage its personnel. 

• Euture Challenges (High): Given the preearious state of readiness and the 
unparalleled efforts of the Navy in retaining more eapable, more 
experieneed, more teehnieal workforee, reduetions to PERSYS now or in 
the future aeross the EYDP will lead to eritieal failure. The resourees 
alloeated to PERSYS in future EYs must be restored. [RJeeent euts will 
not only impair readiness and retention, but will impaet the ability to 
support migration to the DIMHRS and to develop Navy-unique 
funetionality that will not exist in the DIMHRS. 

• Cons: If PERSYS is not funded, the systems will be shut down, and the 
Navy will be unable to pay, promote, and retire sailors. (Murphy, 2007) 
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This chapter has indicated that the RHS is not alone in the issues it faees. What is 
elear, however, is that any efforts to make the RHS better must be eondueted in eoncert 
with other initiatives taking plaee within the Navy enterprise. Now that the eurrent states 
of the IT systems relative to this study have been examined, the next ehapter will address 
the proposed state of these systems, with particular emphasis on the RHS. 
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III. DESIRED STATE OF INFORMATION SYSTEMS 


A, DEPARTMENT OF DEFENSE (DOD) VISION 

Some believe that with the United States in the midst of a dangerous war 
on terrorism, now is not the time to transform our armed forces. I believe 
that the opposite is true. Now is precisely the time to make changes. The 
war on terrorism is a transformational event that cries out for us to 
rethink our activities, and to put that new thinking into action. 

Secretary of Defense Donald H. Rumsfeld 
Transformation Planning Guidance, April 2003 

The DoD is continuing with many facets of organizational transformation that the 
former Secretary of Defense described. This change is far reaching—to include 
operations related to conducting warfare, acquiring weapon systems, resourcing force 
structure, and designing business processes. In this chapter, the focus is on business 
processes and force structure as related specifically to Human Resources Management 
(HRM). It begins by examining the vision of the DoD in relation to HRM, followed by a 
discussion of how this vision is to be carried out within the Department of the Navy 
(DoN), and finally concludes with a discussion of how this vision will be carried out in 
relation to the Commander Navy Reserve Forces (CNRF) HRM system Reserve 
Headquarters Support (RHS). 

1. Force Integration 

Ultimately, the goal of the DoD—the defense of our nation—has remained 
constant over time. However, the nature of the environment has changed, necessitating a 
shift in culture and practice from a Cold War-oriented force to one that can better deal 
with the complexities of the current post-Cold War era. The Cold War organizational 
force structure can be described as a machine bureaucracy—an organizational 
configuration described by Henry Mintzberg. Machine bureaucracies are structured in a 
highly hierarchical fashion, as is the DoD. In the Post-Cold War environment, the 
effectiveness of this structure is questionable. The nature of our nation’s defense has 
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changed due to the changing face of our real and potential adversaries. This shift has 
required that DoD components adopt more flexible structures that will enable stronger 
relationships between the DoD components. In relation to HRM, this shift can be seen in 
the following passage from an article concerning Global Force Management (GFM). 
“USJFCOM relies heavily on its Serviee eomponents to coordinate with the Serviee 
headquarters and other combatant command Service components to track capabilities and 
forces in order to assess operational readiness, availability, commitment, and capability 
substitution options” (Ferriter & Burdon, 2007, p. 46). To enable this type of 
coordination efficiency, the DoD must transform the way it conducts its business. A large 
part of this transformation will be enabled by a re-tooling of its business processes. To 
this end, the DoD established the Business Transformation Agency (BTA) in October 
2005 and announced its organizational strueture in February 2006. 

2, Business Applications and the Business Transformation Agency 
(BTA) 


a. Defense Integrated Military Human Resource System 
(DIMHRS) 

The BTA is tasked with transforming the business operations of an 
organization that employs three million personnel (uniformed and civilian) throughout 
the world into an organization that can meet the complex requirements of the current 
environment (0MB, 2009). As per the official BTA Web site (BTA, 2009c), the 
Transformation Priorities and Requirements-HRM Directorate serves as the primary li nk 
to the Office of the Undersecretary of Defense (Personnel and Readiness) (OUSD 
(P&R)). The primary products and guidelines produced by the BTA enabling HRM are 
the focus of the next section of this paper. 

b. Business Transformation Agency Products 

The DoD expects that ultimately, under the direction of the BTA, 
personnel-related IT-system issues will be resolved by implementing the Defense 
Integrated Military Human Resource System (DIMHRS). This solution will be phased in 
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starting with the uniformed Armed Serviees, and will ultimately be utilized by all of the 
organizational components within the DoD. The military implementation is expected to 
benefit Service members and their families by “Integrating personnel and pay for all 
service members into a single system [that] will ensure they are paid accurately and on 
time” (ROA of the U.S., 2009). Further, “With a single record of service and integration 
across all uniformed services and Active, Reserve, and Guard Components, transfers 
between components and across the services will be seamless. The DIMHRS also will 
allow commanders to track personnel regardless of location or branch of service and 
ensure the right people are in the right place at the right time” (ROA of the U.S., 2009, p. 
1). Finally, as the DIMHRS is a Web-based application, it follows that, “essential 
personnel records will be instantly available to human resources specialists, commanders, 
personnel and pay managers, and other authorized users” (ROA of the U.S., 2009, p. 1). 
This assertion assumes that connectivity issues will be mitigated. 

3, Guidelines and Enablers to Achieve 

Whether or not the DIMHRS is successfully completed and installed, the direction 
from the DoD remains the same: that its personnel systems must be upgraded to keep 
pace with changing operational requirements and technology. To meet these more 
general requirements as they relate specifically to HRM, the BTA (through the 
Transformation Priorities and Requirements-HRM Directorate) “ensures that the 
functional priorities and requirements of the client organizations, as well as those of the 
Services and Agencies, are accurately reflected in both the Business Enterprise 
Architecture (BEA), the Enterprise Transition Plan (ETP) and the guidance provided for 
business system investment review” (BTA, 2009c, p. 1). A short discussion of these 
elements follows. 


a. Business Enterprise Architecture (BEA) 

In March of 2009, the BTA released Version 6.0 of the BEA, which is a 
comprehensive guide for transforming the business practices of the DoD. The BEA 
provides high-level documentation and guidance for the enterprise on the theories and 
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methodologies that are to be applied to ensure a sueeessful transition. The BEA Web site 
eontains, “a virtual ‘Center of Exeellenee’ and is a useful resource for people interested 
in developing architecture or understanding Service Oriented Architecture (SOA) and 
federation concepts” (BTA, 2009a, p. 1). Eor components and organizations that require 
transformation, such as the OUSD (P&R) and the Navy, the BEA is the ultimate source 
for the definition of requirements, guidelines, and procedures to which DoD agencies 
must adhere. Einally, “The BEA consists of a set of integrated architecture framework 
products that define operational activities, process data, information exchanges, business 
rules, system functions, system data exchanges, terms and linkages to laws, regulations 
and policies associated with the Department’s business operations” (BTA, 2009a, p. 1). 

b. Enterprise Transition Plan (ETP) 

In conjunction with the BEA, the ETP provides greater granularity and 
guidance for the DoD and is the roadmap to be followed concerning the business 
enterprise architecture. According to the ETP Web site (BTA, 2009b), the following list 
defines the scope of this plan: 

• The acquisition strategy for new systems that make up the target enterprise 
architecture, 

• A listing of defense business legacy systems not expected to be part of the 
target environment (as of 2002), 

• A list of the defense business legacy expected to be part of the target 
environment, and 

• Time-phased milestones, performance metrics and a statement of the 
financial and non-financial resource needs. (2009b, p. 1) 

The DIMHRS fits under the first bullet, while the next three bullets 
directly relate to the focus system of this paper, the Reserve Headquarters Support 
(RHS). In the ultimate vision of the future business enterprise, the RHS will not be 
included, as it will be subsumed by the DIMHRS. However, prior to meeting this goal, it 
will be important for the RHS owners to position the application for such a transition by 
modernizing. Therefore, it will be prudent and necessary for the RHS to follow the 
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roadmap provided by the ETP to ensure a smooth transition. Figure 9 from the FTP 
gives a eoneise representation of how the DoD eomponents are integrated within the 
enterprise. The RHS fits within the Navy component. 



Figure 9. DoD Enterprise Capabilities by Component (From BTA, 2009e, p. 4) 


Finally, the ETP is focusing on six business priorities to guide the DoD 
enterprise transformation—including Personnel Visibility (PV), Acquisition Visibility 
(AV), Common Supplier Engagement (CSE), Materiel Visibility (MV), Real Property 
Accountability (RPA), and Financial Visibility (FV). The focus of this paper is on PV— 
which, in the latest version of the ETP (September 2008), is described as “the fusion of 
accurate human resources (HR) information and secure, interoperable technology within 
the Human Resources Management (HRM) Core Business Mission (CBM)” (BTA, 
2009e, p. 35). As such, the DIMHRS falls under PV, and by default, so does the RHS. 

c. Business System Investment Review Guidance 

The final guidance from the BTA that this paper will explore is the 
Investment review Board (IRB) Process. “The process is guided by the BEA and the 
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Enterprise Transition Plan (ETP), which, along with related Component architectures and 
transition plans, provides an integrated view of business functions and a roadmap for 
more robust business capabilities” (BTA, 2009d). Important to the transition of RHS is 
the fact that once the transition process is underway, it will be monitored for progress and 
compliance via an aimual review. This review is applied to business systems that have no 
dedicated modernization funding. The RHS falls into this category because funding for 
modernization is being directed to the DIMHRS and not to systems that the DIMHRS 
will subsume. Eigure 10 shows how the concepts described in this section (PV, the BEA, 
the ETP, and Business Investment Review) fit into the overall DoD enterprise plan. 
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Eigure 10. The Path to DoD-wide Business Agility and Information Visibility 

(Prom BTA, 2009d, p. 3) 


Next, we will examine the OUSD (P&R) in relation to the initiatives it is 
working on in order to meet the goals of the BTA and the DoD. 
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4 . 


Office of the Under Secretary of Defense—Personnel and Readiness 
(OUSD (P&R)) 


Within the OUSD (P&R), the Human Resouree Management Enterprise 
Architecture (HRM EA) Division “coordinates the implementation of Department of 
Defense Architecture Eramework (DoDAE) architecture methodologies to develop HRM 
business area architecture” (P&R IM, 2009, p. 1). Implementation efforts are conducted 
in concert with BTA efforts, and both efforts support one another. More precisely, the 
efforts of the OUSD (P&R) directly support the enterprise transformation efforts of the 
BTA described above. The following description from the OUSD (P&R) Web site 
further illustrates the ties between the BTA and the OUSD (P&R): the “HRM EA 
Division Chief acts as the advisor for HRM business architecture and the liaison for 
HRM Eines of Business capabilities and architecture efforts within DoD, coordinating the 
development of HRM architecture for the Business Enterprise Architecture (BEA).” 
Eurther, the “HRM Enterprise Architecture Division Chief provides authoritative 
interpretations of HRM federation and architecture integration issues within the DoD 
HRM community” (P&R IM, 2009, p. 1). This direction comes from the DoD level to 
the component level, and ultimately will drive and govern the re-engineering efforts of 
the RHS. 

The Operational Vision (OV) of the HRM EA is depicted in Eigure 11. This 
graphic gives a visual representation of the functions that are to be encompassed in any 
Human Resource IT application development. Specifically, these are the functions the 
DIMHRS must cover. As such, any development efforts short of or in support of the 
DIMHRS must be built with these functions or include a pertinent subset of them. 
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Figure 11. OV-1: DoD Personnel and Pay: Fligh-level Operational Concept Description 

(From DoN HCS, 2009) 


B. DEPARTMENT OF THE NAVY (DON) 

In line with the DoD strategy to implement the DIMHRS as the sole personnel 
and pay system used by the Department, the DoN has agreed to migrate to this solution in 
the future. The Federal Computer Week Web site summed up the progress for the 
migration as follows, “The Navy and Marine Corps will move to the Defense Integrated 
Military Human Resources Systems (DIMHRS) after all—but no one is sure when” 
(Miller, 2007, p. 1). Regardless of the outcome of DIMHRS implementation efforts, the 
“DoN is rapidly moving away from a vertical (command and control) model to a 
horizontal (connect and collaborate) model” (ASN (M&RA), 2009, p. 4). In regards to 
the complexities of transitioning from a vertical to a horizontal model, the following 
assessment was made in the DoN DIMHRS Concurrent Review: 
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[TJhere is still a long way to go. Our family of systems must be opened so 
as to inelude both DON eivilian employees and contraetors into our 
workforee planning proeesses. Many of our eivilian employees and 
eontraetors are also reservists. The DON ean no longer afford to maintain 
this data in stand-alone systems. To solve this problem, the department is 
establishing standards for eontent, aecuraey, and interchangeability. 

These same standards are the method by which DON systems will become 
an integral part of a new Defense Integrated Human Resource 
Management Information System —all while meeting the objective of the 
Business Management Modernization Program (BMMP) to gain 
efficiency along the way. (ASN (M&RA), 2009, p. 4, emphasis in 
original) 

The review further asserts that successful modernization will be enabled by 
“pursuing open system standards and data warehouse technology,” with which the “DON 
will not only be able to meet the current joint and COCOM needs, but quickly adapt to 
future requirements as well” (ASN (M&RA, 2009, p. 4). 

From the PEO EIS, Eigure 12 depicts the DoN corollary to the DoD OV-1 shown 
in the prior section concerning the OUSD (P&R). It is shown here to logically illustrate 
the flow of requirements at the various levels within the DoD. The Department of the 
Navy Human Capital Strategy articulates the components of this high-level model as four 
Systems-focused Strategic Goals: Recruit/Access, Manage, Eorce Shaping, and 
Separate/Retire. Eurther, it explains, “All DoN activities involving people will be linked 
and aligned. The system must be transparent and permit people to move back and forth 
between components and workforce categories. Authority and accountability for the 
performance of the process will be vested in a process owner” (ASN (M&RA), 2004, p. 
15). 
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Figure 12. DoN HRM OV-1 in Support of DoD OV-1 
(From DoN HCS, 2009a) 


Additional guidance is provided by the Force Management Oversight Council 
(FMOC) and is reflected in the Department of the Navy Human Capital Strategy of June 
2004. In this document, the ASN (M&RA) describes the FMOC’s requirement to create 
a Total Workforce Management (TWM) solution. TWM will “achieve an integrated 
personnel system of active and reserve military, civilians, contractors, and volunteers, 
and also [explain] how to provide portability and flexibility in utilization of all workforce 
members, as well as flexible career lengths and patterns of service for the military” (ASN 
(M&RA), 2004, p. 16). In addition to these DoN goals. Joint Force Management will 
also need to be met in the future, providing the same set of functions in a joint 
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environment. All of these funetions will need to be provided in a seeure, Web-based, 
global environment—one that adheres to sound data standards to reduce redundancy and 
to leverage transparency and interoperability (DoN, 2005, May 3). 

Going forward, DoN information systems—including those related to Human 
Resource Management (HRM)—are required to be fully integrated solutions within an 
open, Services-oriented Architecture (DoN FMOC, 2006). In addition to the 
aforementioned requirements, there has been a proposal by the Manpower, Persoimel, 
Training and Education (MPTE) Chief Information Officer (CIO) code NI6, to combine 
the data into one cleansed, metadata tagged, indexable and searchable Enterprise Data 
Environment (EDE) (Navy MPTE, 2008). This environment will resolve redundant 
storage issues, as well as eliminate outdated, end-of-lifecycle equipment and legacy 
infrastructure. Eigure 13 depicts the vision of the Navy Program Executive Office (PEO) 
for Enterprise Information Systems (EIS) of how data from the current MPTE system 
will be mapped to the proposed future state of DoN HRM information systems. 
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Eigure 13. Euture MPTE Information Technology System Structure 

(Erom Murphy, 2007, slide 10) 
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The vision painted in Figure 13 fits into the overall Chief of Navy Personnel 
(CNP) vision of the future enterprise, which is shown in Figure 14. This figure illustrates 
the Data Management and Integration (DM1) matrix model. The DM1 approach provides 
necessary control, information exchange, and efficiency of data operations. “To achieve 
this, data governance, data architecture, and data sharing—the ‘Three Pillars’ of data 
management—^provide the framework for the operational focus of the DM1 Roadmap” 
(Pavelec, 2008, p. 2). Within the matrix, the MPTE databases are represented in the 
orange cubes as the basis for the Enterprise Data Environment (EDE). It is to this new 
model that the RHS will be required to migrate. 
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Eigure 14. Chief of Navy Personnel (CNP) IT vision 
(Prom Murphy, 2007, slide 10) 
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1, Enterprise Data Environment 


In 2008, the MPTE CIO directed that an Enterprise Data Environment (EDE) 
proof-of-concept pilot project be executed by the Space and Naval Warfare Systems 
Command, New Orleans (SSC NOEA). In the Statement of Objectives, the PM for the 
project described the SSC NOEA’s objective this way: “an agile and trusted, fully 
integrated data environment that is built on a Services Oriented Architecture (SOA) to 
provide the foundation for net-centric data services to the enterprise” (Navy MPTE, 2008, 
p. 1). Six specific objectives from the Statement of Objective relating to the EDE follow: 

1. Develop an N1 (Navy Personnel) Enterprise Information Management (EIM) 
framework detailing management practices, governance, accountability, and 
metrics to drive data-quality improvement; 

2. Eacilitate the validation of the N1 EIM framework to determine if it is executable 
and repeatable; 

3. Prove the adaptability and scalability of the SSC NOEA EDE; 

4. Meet the OPNAV N6 (Deputy Chief of Navy Operations (CNO) Communication 
Networks) goals and objectives described below; 

5. Integrate N1 data from legacy systems to a modern SOA-capable data store— 
providing a single source of clean, integrated, active and reserve manpower and 
personnel data; 

6. Determine whether the EDE is a viable source for clean, authoritative data to 
support DIMHRS data migration. (2008, p. 1) 

As of June of 2008, SSC NOEA staff assigned to the pilot project had 
successfully migrated MPTE data from the Navy Enlisted System (NES) and the Officer 
Personnel Information System (OPINS) to the EDE. Some benefits from the project are 
listed below. Their corresponding objective numbers from the Statement of Objectives 
are captured in parentheses: 

• Successfully developed and implemented a data-integration strategy (2, 3, 
4, 5), 

• Defined data logic and business processes (1, 2, 3, 4), and 

• Created authoritative documentation (1). 
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Successful completion of the EDE pilot projeet marked the first time that the 
Navy data environment demonstrated the use of “modern data engineering methods (e.g., 
SOA, metadata) to implement a system that satisfies the major challenges” of data 
management and migration (SSC New Orleans, 2008, slide 18). In addition, the pilot 
data that was migrated was “clean, useable, authoritative, and up to date” (slide 18). 
These results are in accord with the Navy’s plan regarding its data management and the 
teehnologies used; these results also met with the objeetives that the MPTE CIO defined 
for the EDE pilot projeet. 

Subsequent to the EDE pilot project and in support of the CNP Vision, SSC 
NOEA has been directed by the MPTE CIO to support the “migration of the Navy's 
legaey manpower and personnel information systems data and functionality into an EDE 
that offers seeure, accurate, authoritative information” (SSC NOEA, 2009, p. 1). 
Additionally, SSC NOEA has proposed that the EDE solution be used as a way to 
position MPTE information systems for eventual migration to the DIMHRS, and that 
Navy-unique data (non-DIMHRS) be transferred as well. Eurther, SSC NOEA has 
proposed that the EDE be used as “the foundation for N1 IT legaey modernization—even 
if DIMHRS fails” (SSC NOEA, 2008, slide 16). Eigures 15 and 16 depict the DIMHRS 
alternative migration strategies designed by SSC NOEA. Eigure 15 (direet solution) 
shows the direet transition of N1 (MPTE) legaey systems to the DIMHRS, while Eigure 
16 (EDE solution) depicts a transition to an EDE prior to migration to the DIMHRS. The 
direet solution would require “investment to develop and implement a data integration 
strategy, with solution arehiteeture, to deliver capability,” and both “Technical and 
functional governance risks apply” (SSC NOEA, 2008, slide 20). On the other hand, the 
EDE solution would benefit from the work eompleted and lessons learned on the EDE 
pilot project; in addition, the “Remaining N1 portfolio leverages component SOA 
arehiteeture” (2008, slide 20). In this seenario, the teehnical risks of migrating direetly to 
the DIMHRS would (aecording to SSC NOEA) be “dramatically mitigated” (2008), 
while functional governance risks would still apply. 
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Figure 15. MPTE Transition Options—Move Directly to the DIMHRS 

(After SSC NOLA, 2008, slide 20) 



Figure 16. MPTE Transition Options—Move an EDE Eirst 
(After SSC NOEA, 2008, slide 20) 

The resulting MPTE system diagram seen in Eigure 16 would be significantly 
cleaner than the current state shown in Chapter 1, Figure 1. 

Finally, according to SSC NOEA, the EDE offers cost reductions of 30-50% 
below current systems costs in development and Operating and Maintenance (O&M) and 
also provides a more flexible system for less expensive and more efficient changes in the 
future. Currently, it appears that the SSC NOEA EDE is the most likely solution for RFIS 
migration. The next section focuses on the desired state of the RHS. 
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Figure 17. Desired/Future MPTE System Overview 
(From Murphy, 2007, slide 8) 


C. RESERVE HEADQUARTERS SUPPORT (RHS)—DESIRED STATE 

In this seetion, we turn our attention to the focus system of this paper; the Reserve 

Headquarters Support (RHS). Here, the desired state of the RHS is defined from the 

perspective of the system owners, the Commander Navy Reserve Force Command 

(CNRFC) Nl-Chief of Personnel, and the N6-Chief Information Officer (CIO); 

however, we still recognize the desired IT system state of those higher Echelons 

discussed previously. CNRFC is fully aware of the shortcomings of the RHS as it exists 

today and is committed to creating a system that is modern, compliant and flexible. To 

this end, CNRFC (business owner of the RHS) requested that SSC NOEA (technical 

owner of the RHS) conduct a RHS technical re-engineering study in Eebruary of 2008. 
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The primary objective of this study was to assess the cost to “Migrate the current RHS 
Application to a more modem technology and architecture. This includes hardware and 
software upgrades that are Navy and DoD Information Assurance Compliant. The cost 
proposal includes all of the work necessary to accomplish this objective” (Robertson, 

2008, p. 11). 

The study specified the following services, deliverables, and assumptions: 
Services: (to be provided by SSC NOLA) 

• Migrate the RHS application to a multi-tiered Java/Web-based 
architecture, 

• Upgrade current database software, 

• Re-write the current application, and 
Train personnel on the new system. 

Deliverables: 

• Completed set (baseline) of functional requirements implemented in the 
RHS application, 

• An upgraded and re-designed set of software components, 

• Upgraded database, 

• Systems Security Authorization Agreement (SSAA), and 

• Modernized development, test, and production environments—including 
hardware, software, and infrastmcture. 

Assumptions: 

• No additional hardware, software, or licensing will need to be purchased 
beyond that already identified in this IPE. 

• The new application will only contain existing system functionality. 

• CNRFC will designate and assure availability of responsible and 
knowledgeable personnel, as scheduled in the project plan, to: 

• Review and approve system requirements, 

• Perform beta testing for each build, 

• Perform user acceptance testing, and 

• Support the production environment transition activities. 
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• Implementation Training will be eondueted by SSC NOLA personnel at 
SSC NOLA. (Robertson, 2008, p. 12) 

Together, these serviees, deliverables and assumptions eombine to ereate a list of 
requirements that will help CNRFC reaeh its desired state pertinent to the RHS. They 
define “what” the future system must do without dietating “how” to do it. This 
distinetion is important, as it leaves the arehitectural possibilities wide open in regards to 
the system’s eventual re-engineering. Also important to note is that only existing 
funetionality is to be migrated to the new solution; sueh speeifieity may help to eontrol 
the possible problems assoeiated with migration. CNRFC desires that the teehnology 
underlying the RHS be updated so that it will work more effieiently, be compliant with 
DoD instructions, be interoperable with other DoD systems, and be readily upgradeable 
to meet future requirements. 

1. How to Get to the Desired State 

Figure 17 shows the MPTE CIO’s perspective in regards to how the MPTE 
organization will look from a data management standpoint. Of particular interest in this 
section is the role that the RHS plays in this environment. It will be expected to be 
capable of fitting into the Shared Services portion of the Navy enterprise architecture by 
being accessible to other applications within the enterprise. As such, it will need to be 
compliant with the strategy, policies, data management standards, reconciliation, and 
quality assurance aspects of the Enterprise Information Management (EIM) strategy. 
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Figure 18. To-Be MPTE Data Management Environment (Pavelee, 2008, p. 4) 


2, Architecture Possibilities 

To reach this state, the Navy has decided to implement a Service-oriented 
Architecture (SOA), which is an architecture that is based upon a meshing of software 
services provided by different system owners. This type of architecture does not rely on 
hard-coded calls to other systems; instead, the services offered by an organization are 
published, and organizations seeking the kind of service offered can pull the information 
from the services it desires. The following description of an SOA provided by the Naval 
Network Warfare Command is instructive. 

FORCEnet requires a service-oriented architecture based on several 
principles. First, any node can establish a presence on the network through 
which it can post the nature and location of its services and information. 
Second, others can easily find that node through accessible addressing. 

Third, others can then access the information and services they require, 
subject to necessary restrictions. Nodes will generally gain access to 
information and services by subscribing to them. In this way, decision 
makers choose, or “pull,” the information they need for their decision¬ 
making. This general “pull” approach should be balanced by intelligent 
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“push,” whereby decision makers receive exceptional information they 
have not requested but which is deemed by some authority to be important 
to them. (2009a, p. 11) 

From the RHS re-engineering project discussed previously, CNRFC proposes to 
meet this state by making the RFIS a Web-based application. By doing so, the RHS will 
be accessible to other enterprise applications that are also Web-based—thereby making 
itself accessible within an enterprise SOA. Figure 18 depicts the organization of the 
MPTE EIM concept, wherein the RHS would reside in Echelon III as part of the Pay & 
Personnel service governed by Echelons I and II. 



Eigure 19. Enterprise Information Management (EIM) Organization for MPTE 

(Erom Pavelec, n.d., slide 8) 
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In conjunction with the above-stated serviees, deliverables, and assumptions 
defined by CNRFC, the following guidance from the MPTE CIO further defines the 
requirements for which the RHS will be responsible; 

• Integration with cross-functional domain areas, 

• Data, metadata management and semantie reconciliation, 

• Data integration aeross the IT portfolio, including: 

• Systems/Apps (SOA) 

• lA 

• Provision of unify-able and eonverge-able eontent, and 

• Ability to meet with govemanee: 

• Standards 

• Cost eontrol 

• Enterprise and strategie alignment. 

Combining all of the elements of the re-engineering project and the above 
guidance from the MPTE CIO, a workable list of requirements can be pieced together 
that defines the desired state of the RHS. This requirements list will be in accordance 
with the direction set forth by the DoD and further refined by the DoN, while making 
sure that the RHS beeomes a more useable application both now and into the future. 

3. Acquisition/Development Method 

Table 3, taken from the PEO EIS (Murphy, 2007, slide 30), shows the eurrent 
funding level (baseline) and the proposed funding level of the RHS. Currently, only the 
system’s Operation Maintenance Navy (OMN) is funded. Clearly, CNREC eannot 
provide the desired level of service with the current level of funding. Even the proposed 
funding level—which shows OMN continuation, along with proposed Research 
Development Training and Edueation (RDT&E) funding—by itself is inadequate to meet 
the envisioned future state of the RHS. 
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Table 3. Reserve Headquarters Support (RHS) Funding and Proposed Changes 

(*figures in thousands) 

(From Murphy, 2007, slide 30) 


APPN/LI/P1FY08 

FY09 

FY10 

FY11 

FY12 

FY13 

FY14 

FY15 

FYDP 

PR-09 Baseline 

OMN 

812 

1000 

0 

0 

0 

0 

0 

0 

1812 

RDTE 

0 

0 

0 

0 

0 

0 

0 

0 

0 

OPN 


POM-10 Proposed 









OMN 

874 

998 

1033 

1069 

1106 

1145 

611 

632 

7468 

RDTE 

0 

0 

1000 

1250 

1250 

1000 

0 

0 

4500 

OPN 

Delta 

OMN 

(62) 

2 

(1033) 

(1069) 

(1106) 

(1145) 

(611) 

(632) 

(5656) 

RDTE 

0 

0 

(1000) 

(1250) 

(1250) 

(1000) 

0 

0 

(4500) 

OPN 


Funding-level estimates taken from the RHS Cost Migration Model (Figure 19) 
put the cost of the effort over $13 million in RDT&E funding alone, versus the $4.5 
million proposed in the PEO EIS plan. 


14 Estimated Cost The estimated cost for the RHS Technical Re-enaineerino 

Application Software Development 

$12,922,547 

Database & AppA/Veb Server Setup & Config 

$ 30,000 

Implementation and Training 

$ 30,000 

Software and Licensing 

$ 50.000 

Security 

$ 54,000 

TOTAL RDT&E 

"$13,086,547 



Eigure 20. SSC NOLA Estimate to Re-engineer RHS (Erom Robertson, 2008, p. 12) 


To meet the proposed desired state of the RHS, decision-makers must draft a 
realistic funding estimate. The estimates of both the PEO EIS and SSC NOLA need to be 
considered. Thus, possible research could be conducted reconciling these estimates and 
using them as baselines from which to draft an estimate. The estimate must recognize the 
requirements for the functionality of the system (described herein), along with the timing 
of the execution of the proposed funding. Additionally, funding that has been 
appropriated for the migration of Navy data to the DIMHRS should be studied to 
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determine if any of those funds would be more appropriately directed towards the efforts 
of re-engineering the RHS. By re-programming the RHS DIMHRS funding to RDT&E 
and Operation Procurement Navy (OPN) for the RHS, CNRFC will assume control over 
re-engineering efforts. It would then be able to move the RHS to an EDE regardless of 
the future platform (DIMHRS included). This solution would enable the RHS to attain 
the desired state and make it possible for the system to be integrated more readily at a 
later date by the DIMHRS, or by any other SOA-based product. 

As discussed earlier, SSC NOEA has demonstrated the ability to transfer 
application data to an EDE. The next step is to ensure the appropriate stakeholders: 1) 
create a transfer plan that includes a prioritized list of systems to migrate to the EDE, and 
then 2) execute the plan. If this happens, programs will be funded for migration based 
upon their priority level. This process will allow for incremental gains towards an overall 
enterprise solution. 

In this chapter, the desired state of information systems has been described from 
the DoD organizational level down to the RHS system level. Challenges associated with 
creating the desired state for the RHS have been described in terms of technical, 
personnel, and acquisition hurdles. In the next chapter, solutions will be proposed to 
overcome them. 
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IV. PROPOSED WAY FORWARD AND ASSOCIATED COSTS 


To this point, this research has focused on describing known or verifiable facts 
about the information technology systems related to Human Resource Management 
(HRM) within the Department of Defense (DoD). The current state and desired states of 
the pertinent IT systems and their associated business processes have been described. In 
this chapter, focus will shift to examining philosophies, tools, and techniques that can be 
used to transition current systems to desired end-states. To begin, the DoD will be 
examined, and essential elements that need to be in place at this level for downstream 
systems to be successfully implemented will be discussed. Focus will then shift to 
examining how the Department of the Navy (DoN) can further enable successful 
transformation of its IT assets in support of the DoD. Next, the Reserve Headquarters 
Support system (RHS) will be studied to determine the steps that will need to be taken to 
ensure its future success within the business application portfolio of the Navy and DoD. 
Finally, costs associated with three alternative states of the RHS will be discussed. 

A. DEPARTMENT OF DEFENSE 

Chapter II described IT systems and business processes within the DoD as being 
highly partitioned and poorly suited to support cross-organizational business practices 
and processes. In particular, efficient and effective utilization of human assets has 
proven to be difficult in a joint organization environment. Chapter III then described the 
desired state of business process IT applications that would rectify many of the current 
shortcomings. In fact, much progress has been made to this end. A great deal of 
guidance has been forwarded to the DoD from Congress describing what DoD-related IT 
systems must be able to do and, in some cases, the necessary steps to do it. Although this 
type of guidance has been in place long before 2005, this year is important because it 
marked the creation of the Business Transformation Agency (BTA). Through the BTA, 
the guidelines and rules provided by Congress have been codified and institutionalized in 
the form of the Business Enterprise Architecture (BEA), the Enterprise Transition Plan 
(ETP), and the Business Investment Review Boards (IRBS). These tools provide a 
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starting point and reference material for all entities that operate within the DoD that are 
engaged in transition-type projects. In the following paragraphs, some ideas on how to 
increase the likelihood of successful implementation of the BTA’s vision are discussed. 

1. Building a Foundation for Execution 

In their research, Ross, Weill, and Robertson studied hundreds of companies that 
have experience in implementing enterprise architectures. They found that the companies 
that were the most successful in this endeavor followed some common practices. These 
findings form the basis for their assertion that to successfully execute business strategies 
through IT solutions, companies must master the three following disciplines. 

1. They must establish and use an operating model. This is highly 
important to this study, as “it forces a common understanding of data across diverse 
business units” (Ross, Weill & Robertson, 2006, p. 8). This commonality is ultimately 
what the RHS, the Navy, and the DoD would like to achieve. The operating model 
describes the amount of process integration necessary within an organization to 
successfully deliver services to the customer. (More on this is described in the following 
section, choosing an operating model.) 

2. Implement and use enterprise architecture. Ross et al. (2006) 
explain that, “The enterprise architecture is the organizing logic for business processes 
and IT infrastructure, reflecting the integration and standardization requirements of the 
company’s operating model” (p. 9). Further, an enterprise architecture enables individual 
projects to “build capabilities—not just fdl immediate needs” (p. 9). This step ties the 
operating model to the IT systems of the organization. 

3. Develop and use an IT engagement model. An engagement model 
presents the rules established by the organization’s headquarters that must be followed by 
subordinate business units. This is where an organization’s internal and external 
regulations, technical standards, development and implementation standards are 
addressed. 
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Why is building a foundation for execution important to the DoD? First, 
Ross et al. (2006) explain that companies that have a solid foundation have proven to be 
more efficient and flexible to shifting customer demands—which are common within the 
DoD. This is followed by the assessment that as a company increases in size and its IT 
systems become more complex, those systems run the risk of becoming inflexible—thus 
creating a situation in which changes to the system “becomes a risky, expensive 
adventure” (p. 11). Examples of this danger are numerous in the DoD; the RHS is one 
such example. A strong foundation for execution helps to alleviate these negative effects 
by providing the organization with a scalable foundation. Additionally, a solid 
foundation leads to more readily shareable data, giving the organization the flexibility 
needed to adjust to new requirements and regulations. This is one of the primary goals of 
the BTA, as it works to implement enterprise architecture at the DoD level and to 
incorporate subordinate organizations’ business IT functions. Finally, as the foundation 
matures, business processes become more efficient, and IT costs are lowered. 

2. Choosing an Operating Model and Implementing the IT Engagement 
Model 

In their book. Enterprise Architecture as Strategy, Ross et al. (2006) present four 
possible operating models from which organizations could choose. This decision should 
be based upon the models’ fit to their organization’s business model. The models contain 
four quadrants based upon two axes: vertical axis determines business process integration 
and horizontal axis corresponds to business process standardization. Ross et al. describe 
integration as linking “the organizational units through shared data” (2006, p. 27). 
Likewise, they identify standardization as “defining exactly how a process will be 
executed regardless of who is performing the process” (p. 27). The four quadrants are 
based upon where in the spectrum an organization lies regarding these two metrics— 
either low or high. Table 4 shows the four types of operating models and their associated 
characteristics. 
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Table 4. Four Operating Models (After Ross, et al., 2006, p. 29) 


I 

n 

t 

e 

g 

r 

a 

t 

i 

o 

n 


Coordination 

Unification 

- Shared customers 

- Customers and suppliers 

- Impacts other business 

local or global 

unit transactions 

- Globally integrated 

- Operationally unique 

business processes 

business units 

- Business units w/ similar 

- Autonomous business 

or overlapping operations 

management 

- Centralized management 

- Bus. unit control over 

applies functional/process 

process desicfn 

unit matrices 

- Shared customer data 

- High-level process owners 

- Consensus processes for IT 

design standard processes 

infrastructure services; IT 

- Centrally mandated 

app. decisions made in Bus. 

databases 

units 

- IT decisions made 
centrally 

Diversification 

Renlication 

- Few shared customers 

- Few shared customers 

Independent transactions 

- Transactions aggregated 

Operationally unique 

at high level 

business units 

- Operationally similar 

- Autonomous Bus. Mgmt. 

business units 

- Business unit control 

- Business unit leaders w/ 

over processes 

limited process control 

- Few data standards 

- Central control over 

- Most IT decisions made 

business process design 

w/in business units 

- Standard data definitions 
with locally owned data and 
some aggregation 

- Centrally mandated IT 
services 

Low 

Standardization 

High 


The BTA has somewhat defined the type of operating model for the human 
resource management (HRM) business function of the DoD as Unification. This is based 
upon the fact that the DIMHRS is the proposed sole solution for the human resource 
function of the DoD—incorporating a high degree of both cross-organizational business 
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process standardization and process integration. Whether this is the appropriate ehoiee or 
not is debatable and will be revisited later in the paper. For now, it will be assumed that 
the unification operating model is a better option than the eurrent diversification 
operating model that is typified by both low proeess standardization and integration, and 
is the proper choice to enable the transition from the eurrent state of DoD IT-related 
business systems to the desired end-state. The DoD has given considerable focus to the 
development of an IT Engagement Model whieh is a neeessary component to ereating a 
foundation for suecessful exeeution. As diseussed in the opening paragraph of this 
section, the BEA, ETP, and the IRBS form the library of guidance and standards under 
which the DoD will continue its IT systems transformation efforts. In the next seetion, 
attention is turned to the next step in creating a foundation for exeeution; implementing 
the operating model through enterprise arehitecture. 

3, Implementing the Enterprise Architecture 

Step two of building a foundation for execution is to implement the enterprise 
arehiteeture based upon the selected operating model, as the process is different for all 
four models. As the DoD has adopted the unification operating model, the enterprise 
arehiteeture diagram would be similar to that depleted in Eigure 21. 



- Required 
. Optional 


O) 

<z> 

ci:> 


Business 

process 

Data 

Technology 


Customer types 


Eigure 21. Unifieation Model EA Diagram (After Ross et ah, 2006) 


61 



















































This diagram represents the strueture that a sueeessful implementation of the 
DoD’s ehosen operating model eould take. In the diagram, there are relatively few 
business proeesses shown, refleeting the high standardization assoeiated with the 
eoordination model. For example, the long eylinder (business proeess) at the bottom of 
the diagram would be a elose approximation of the DIMHRS, in whieh all DoD 
personnel and pay systems would be standardized and integrated with organizational data 
via teehnology. The diagram also aeeounts for small amounts of business-unit-speoifie 
funetionality, as ean be seen by the non-enterprise-eonneeted teehnology loop highlighted 
in red in the diagram. 

4, DoD Stage of EA Maturity 

As an organization deeides to adopt an enterprise arehiteeture, Ross et al. (2006) 
explain that it will progress through four stages of maturity. Although it is not neeessary 
to reaeh level four, it is neeessary to proeeed from the lower levels of maturity before 
attaining higher levels. In other words, stages eannot be skipped. Per the Ross et al. text 
(2006), the four stages of maturity and a brief deseription of the assoeiated arehiteetures 
follow. 

1. Business Silos: Individual business and funetional units’ needs are maximized. 

2. Standardized Technology: Teehnology standardization inereases effieieneies, and 
teehnology management is generally eentralized. 

3. Optimized Core: Provides organization-wide data and proeess standardization. 

4. Business Modularity: Business proeess eomponents are available for reuse and 
preserve organizational standards while enabling loeal differenees. 

Currently, as deseribed in the previous ehapter, the DoD via the BTA is seeking to 
eventually progress through all of the levels of maturity. It is elear that the BTA has 
eorreetly assessed the DoD’s eurrent level of maturity as falling within the Business Silo 
stage. What is not elear is whether the guidanee they have issued leads to Stage Two 
(Standardized Teehnology) or Three (Optimized Core). In order to be sueeessful in 
instituting an organization-wide EA to reaeh the desired state of IT systems, guidanee 
from the BTA must elearly be direeted to aehieving Stage Two maturities before 
progressing to Stage Three. This is due to the faet that eaeh stage implements building 
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blocks that will be built upon by successor stages. The progression through the stages is 
similar to the construction of a building where a roof cannot be applied until after the 
walls have been erected. 

5. Application within the Department of Defense 

By incorporating elements discussed (the operating model, enterprise architecture, 
and IT engagement model), the DoD will not only transition its own business processes 
and supporting IT systems, it will also provide a roadmap for its subordinate 
organizations to follow. In addition, it will provide concrete direction for subordinate 
organizations on how to modernize all levels of the organization by codifying the steps to 
do so. In the research conducted for this paper, the author has found that the BTA has 
made progress towards mastering, articulating, and implementing these disciplines. In 
the case of the DIMHRS, an operating model has been chosen (Unification); copious IT 
engagement guidance has been published, and progress has been made in incorporating 
an enterprise architecture. 

B, DEPARTMENT OF THE NAVY 

In this chapter, methodologies to transform the information technology (IT) 
systems of an organization have been described drawing heavily from the Ross et al. 
(2006) text. The steps to do so include creating a foundation for execution, selecting an 
operating model, implementing the operating model via enterprise architecture (EA), and 
developing an IT engagement model. These steps were then applied to the DoD and to 
the steps the BTA has taken to proceed from the current state of DoD systems to the 
desired state of IT systems, with particular emphasis placed on the human resource 
application, the DIMHRS. In this section, attention turns to the Department of the Navy 
(DoN) and the steps it must take to reach its desired state of IT systems. Particular 
attention will be placed on the operating model, enterprise architecture, and the IT 
engagement model. Finally, an assessment will be made regarding the decisions the DoN 
must make to be successful in transforming its business IT processes and systems. 
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1. 


The DoN Operating and IT Engagement Models 


[I]f all forces and organizations down to the level of individual entities are 
intereonnected in a networked, eollaborative command and control 
environment, then all operations and activities can enjoy the benefits of 
decentralization—initiative, adaptability and increased tempo—^without 
saerificing the coordination or unity of effort typically associated with 
eentralization. (NETWARCOM, 2009a, p. 1) 

The above passage from the Naval Network Warfare Command’s 
(NETWARCOM) EORCEnet concept paper seems to clearly indieate that the Navy has 
chosen to implement a eoordination operating model. It describes an environment in 
which IT systems are highly networked and integrated, while business process deeision 
authority is maintained at the sub-organizational level. To help illustrate, the 
coordination quadrant (Table 5) taken from Table 4 shows operationally unique business 
units controlling process design while leveraging shared customer data. 


Table 5. Coordination Quadrant from the Eour Operating Models Table—Table 4 

Coordination 

- Shared customers 

- Impacts other business 
unit transactions 

- Operationally unique 
business units 

- Autonomous business 
management 

- Bus. unit control over 
process design 

- Shared customer data 

- Consensus processes for IT 
infrastructure services; IT 
app . decisions made in Bus. 
units 


It is interesting to note that this choice of operating model differs from that of the 
DoD, which has chosen the unification model. This differing choice by a subordinate 
organization should not cause alarm; the Ross et al. (2006) text explains, “Having 
different operating models at different organizational levels allows” an organization, “to 
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meet the multiple objeetives of large, complex companies while keeping organizational 
design reasonably simple at the individual operating company level” (2006, p. 40). The 
author would argue that it makes more sense for the DoN to apply the coordination model 
than the unification model for the following reasons: 

• Easier to implement, because it minimizes changes to business 
applications. 

• Allows the organization to focus on increasing IT system integration. 

• Enables continued use of legacy business applications that were 
customized to address the particular needs of the organization and its 
customers. 

These are just a few of many potential examples of why selection of the 
coordination operating model should enable the DoN to complete the transition from its 
current state of IT systems to the desired state. The effects of this choice on personnel 
systems will be examined from a Commander Navy Reserve Eorces (CNRE) perspective 
in a later section. 


a. IT Engagement Model 

Eor the Navy, the IT engagement model has been given careful 
consideration, as is evident from the following passage from the NETWARCOM: “To 
support standards and policy compliancy, organizations developing [Department of 
Defense Architecture Eramework] DoDAE architecture products will receive guidance 
from the EORCEnet Integrated Architecture for development of architectures for their 
[Program of Record] POR as required to support the Joint Capabilities Integration and 
Development System (JCIDS) documents or for other purposes” (NETWARCOM, 
2009b, p.l). Eurther, Eigure 22 illustrates the organizational structure that will be utilized 
to ensure compliance with the IT engagement model. Combined, this corporate-level 
guidance, along with supporting guidance from the DoD, should be ample to guide the 
DoN through the transformation of its business IT systems. 
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Figure 1 - FORCEnet Architecture Governance Organization 


Figure 22. Navy IT Governance (From NETWARCOM, 2009b, p. 2) 


2, Implementing the Enterprise Architecture 

As discussed, the DoN has chosen to install a coordination operating model; thus, 
it must build an enterprise architecture (EA) specifically tailored to support this choice. 
Figure 23 shows the basic design of such an architecture. Notice that the arrows at the 
top of the diagram focus on shared customers and data, integrated technology and linked 
processes. This differs from the unification model, most notably in the area of customers 
(key V. shared) and process standardization. Again, it is not a problem to utilize different 
operating models at different levels of the organizations, and integration of different 
operating models is possible. In the case of integrating the DoN operating model into the 
DoD architecture, the DoN architecture would be treated as a customer within the DoD 
architecture. This would still allow the DoD to meet its goal of providing department- 
level data to the entire organization while allowing the DoN to build an EA that meets its 
individual business needs. 
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Figure 23. Coordination EA diagram (After Ross et al., 2006) 


3, DoN Stage of EA Maturity 

Similar to the DoD, the DoN is currently in the first stage of the maturity model 
(business silos) and is working towards achieving Stage Two (standardized technology). 
In the author’s view, the Navy has a clear understanding of where it stands in regards to 
EA maturity. Evidence to support this position includes the realization that it has no 
existing EA and has addressed the building of one via FORCEnet. “The EORCEnet 
Integrated Architecture is the first naval enterprise level architecture that will guide 
multiple programs of record (FOR)” (NETWARCOM, 2009a, p. 1). Additionally, the 
selection of the coordination operating model reflects that the DoN has a keen sense of 
self-awareness, as this model is a better fit for organizations working to reach the 
standardized technology stage. Indeed, the coordination operating model by definition 
assumes that an organization has already met Stage Two maturity because the 
distinguishing factor of Stage Three (optimized core) is the focus placed upon process 
standardization. This is not to say that organizations in Stage Two can not position 
themselves for progression to Stage Three, but as Ross et al. (2006) tell us, stages in the 
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EA maturity model can’t be skipped. “In several of the companies we spoke to, ERP 
implementations that tried to skip stages had to be halted or scaled back” (Ross et ah, 
2006, p. 82). Next, we will turn our attention to the CNRE and the Reserve Headquarters 
Support (RHS) system, and the steps of transitioning it to its desired state. 

C. RESERVE HEADQUARTERS SUPPORT (RHS) 

In this section, we focus on the Reserve Headquarters Support (RHS) system. As 
the RHS is a subordinate system, and the CNREC is a subordinate organization to the 
DoN and DoD, the latitude in choosing the elements to build a foundation for business 
execution is constrained by the parent organizations’ choices. In other words, the RHS’s 
operating model will either be the coordination model (DoN and the Enterprise Data 
Environment (EDE)) or the unification model (DoD and the DIMHRS), and the IT 
Engagement model used will be the EORCEnet Integrated Architecture process described 
in the previous section. The implementation of the operating model via enterprise 
architecture would follow the diagram associated with the chosen operating model. In 
the following evaluation for the RHS transformation, three alternatives will be presented 
and briefly described. These alternatives will then be evaluated using the Department of 
the Army Economic Analysis Manual as a guide to determine the best choice for the RHS 
transformation. 

1, Economic Analysis of the RHS Alternatives 

The overall evaluation process will follow the model depicted in Eigure 24. 
According to the United States Army Cost and Economic Analysis Center (USACEAC) 
EA Manual, 

EAs facilitate the decision process by providing a strong analytical 
framework for evaluating alternatives, identifying costs and issues, 
highlighting implications of individual alternatives, identifying variables 
that drive results, assessing risks, uncertainties, and sensitivities of 
assumptions and costs, and suggesting recommendations. These elements 
comprise the EA process. (USACEAC, 2001, p. 5) 
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It should also be noted that per the EA Manual (p. 6 and 7): “an EA will not: 

• Produce results that are more valid than the data used in the 
analysis. 

• Make final decisions. 

• Be applied with cookbook precision; instead it should be tailored to 
fit the problem. 

• Provide relevant solutions to irrelevant questions and problems. 

• Predict political and non-economic impacts. 

• Substitute for sound judgment, management, or control.” 

In this paper, a basic analysis will be conducted in lieu of full economic analysis, 
which would be beyond the scope of the current research. The intent is to provide 
enough analysis of the alternatives to be able to choose the best from among them. This 
research could form the basis for a more in-depth study at a later date. 

In the following analysis, the Reserve Headquarters Support (RHS) application 
and potential replacement technologies are examined. The steps will be numbered from 1 
to 7, and each step’s function (what it is trying to elicit) will be described {italicized) 
based upon the Department of the Army—Economic Analysis Manual (USACEAC, 
2001), followed by the actual assessment as it relates to this study. Some of the steps will 
require a discussion and justification of the chosen elements. These discussions will 
follow the seven steps’ EA as they are material to, but not an actual part of the analysis. 
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Figure 24. Economic Analysis Process Model (From USACEAC, 2001, p. 7) 


1. Establish objective. This is a clear identification of the mission-related 
objective(s) and should be consistent with the existing Mission Need Statement (MNS), 
the Operational Requirements Document (ORD), or other approved requirements source, 
as applicable. 

The objective of this project is to “Migrate the current RHS application to a more 
modem technology and architecture. This includes hardware and software upgrades that 
are Navy and DoD Information Assurance compliant” (Robertson, 2008, p. 11). 

2. Formulate assumptions. This is the identification of assumptions with 
underlying rationale explained in the analysis. 

• Project Fife. The project to implement one of the alternatives to 
the status quo should not take so long that it creates prohibitive 
monetary costs or that the benefits of the alternative are diminished 
to a level below that of the current system. 
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• Economic Life. The amount of time that this projeet (as with other 
large teehnology projeets) is expeeted to be benefieial is set at 10 
years after being put into produetion. 

• Funding will be provided by the DoN or DoD. 

3. Identify constraints. Identification and full explanation ofproject constraints: 
assumed or imposed. 

— The solution that is ehosen must fit within the FORCEnet Integrated 
Arehiteeture framework. 

— The solution needs to be Navy and DoD Information Assuranee compliant. 

— The solution must be funded. 

4. Identify alternatives. This step includes identification of the status quo and all 
feasible alternatives. If a candidate alternative is eliminated, specific reasons for 
dropping that alternative must be documented in the analysis. 

Alternative 1—Do Nothing (maintain status quo) 

In this alternative, the RHS applieation would remain as it exists in produetion 
today, with all of its features and inherent flaws as deseribed in Chapter II—Current State 
of Information Systems, Seetion C, Reserve Headquarters System (RHS). 

Alternative 2—Build to the DIMHRS Standard 

This alternative would involve positioning the RHS system for a direct transition 
to the DIMHRS. This option would be eontingent upon definitive direetion from the 
Business Transformation Ageney (BTA) and the DoN Chief Information Officer (CIO) 
that the Navy’s personnel and pay IT systems were slated with an aetual timeframe to go 
live with the DIMHRS. 

Alternative 3—Build to an EDE 

Building to an Enterprise Data Environment (EDE) would follow the solution 
proposed by SSC NOLA in its SSC New Orleans Status Brief on NI Programs and 
Budget Issues (SSC NOLA, 2008). This solution proposes that the RHS be migrated to 
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the EDE regardless of the status of the DIMHRS. In other words, this solution would be 
able to stand on its own, or it could be migrated to DIMHRS at a future date. 

5. Estimate costs and benefits for each alternative. For each alternative, an 
estimate of all anticipated costs, both direct and indirect, over the economic life of the 
project is derived. The methodologies of the cost estimates, and their sources, must be 
clearly identified in the analysis. 

Cost Estimates 

This portion of the analysis adhered to the following guidance; “Investment eosts 
are normally non-reeurring (oeeurring one time or on an intermittent basis) and include such 
items as research and development (R&D), equipment purchases, software development, 
and facilities preparation. Operating and Support (O&S) costs are normally recurring 
(occur on a continuing annual basis) and include such items as operating personnel and 
hardware maintenance” (USACEAC, p. 25). In the following, R&D equates to RDTE, 
and O&S equates to OMN. 


Table 6. POM-10 Proposed Budget 
(Murphy, 2007, slide 30) 


APPN/LI/PfiFYOS 

FY09 

FYIO 

FY11 

FY12 

FY13 

FY14 

FY15 

FYDP 

PR-09 Baseline 

OMN 

812 

1000 

0 

0 

0 

0 

0 

0 

1812 

RDTE 

0 

0 

0 

0 

0 

0 

0 

0 

0 

OPN 


POM-10 Proposed 









OMN 

874 

998 

1033 

1069 

1106 

1145 

611 

632 

7468 

RDTE 

0 

0 

1000 

1250 

1250 

1000 

0 

0 

4500 

OPN 

Delta 

OMN 

(62) 

2 

(1033) 

(1069) 

(1106) 

(1145) 

(611) 

(632) 

(5656) 

RDTE 

0 

0 

(1000) 

(1250) 

(1250) 

(1000) 

0 

0 

(4500) 

OPN 


Table 6 figures will be used in the cost-estimate portion of this EA. Specifically, 

the line item OMN (sustainment) funding will be used as the basis to estimate ongoing 

funding for the three alternatives. The RDTE line will be used for Alternative 2 for 

DIMHRS one-time transition costs, while funding for one-time costs (RDTE) for 

Alternative 3 come from Figure 20. FYIO through FY15 will be used as a baseline to 

establish future year estimates for FY16 through FY19 OMN funding. Current dollars 
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adjusted for inflation 3.5% per year will be used for yearly increases in OMN funding. 
Table 7 shows the total cost by alternative to run each system. 


Table 7. Total Projected Costs of Alternatives 


FY' 

Alternative 1 
(Status Quo) 

OMN RDTE 


Alternative 2 
(DIMHRS) 

OMN RDTE 

Alternative 3 (EDE) 

OMN RDTE 

10 

1.033 


1.033 

1.000 

1.033 

6.543 

11 

1.069 


1.069 

1.250 

1.069 

6.543 

12 

1.106 


1.106 

1250 

611 


13 

1.145 


1.145 

1.000 

316 


14 

1.185 


611 


327 


15 

1227 


632 


339 


16 

1269 


654 


351 


17 

1.314 


677 


363 


18 

1.360 


701 


376 


19 

1.407 


725 


389 



12.115 

OMN Tot. 

8.353 

4,500 OMN Tot. 

5.173 

13.086 



RDTE Tot. 

4.500 

RDTE Tot. 

13.086 



12,115 

Total Cost 

12,853 

Total Cost 

18,259 










Cost totals and method of derivation follow. 

Alternative 1 (Status Quo) - $12,1 million 

For Alternative 1, only sustainment funding (OMN) was estimated, as no 
development investment would be necessary. FYIO through FY15 dollars come from 
Table 6, and FY16 through FY19 dollars were estimated by adjusting for inflation and 
extrapolating FYIO through FY15 dollars. 

Alternative 2 (DIMHRS) - $12.9 milli on 

For this alternative, Table 6 dollars were used for both OMN and RDTE funding. 
FY16 through FY19 funding was calculated using the same method as Alternative 1. 

Alternative 3 (EDE) - $18,3 million 

This alternative required more estimation than the first two alternatives, due to the 
lack of proposed budget dollars in Table 6. For OMN dollars, FYIO, FYll, and FY12 
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were taken from Table 6 as follows: FYIO and FYl 1 used same dollars; FY12 used FY14 
dollars beeause, in this alternative, the EDE projeet would go live during EY12 (thus 
redueing eosts as refleeted in EY14 dollars). Eor EY13 through EY19, OMN costs would 
be further reduced, first by 50% in EY13 (which would establish a new reduced OMN 
baseline) and then by applying the 3.5% inflation rate for years EY14 through EY19. 
This reduction reflects greater expected savings over Alternative 2 because in this 
alternative, all application functionality would be accounted for; yet, in the DIMHRS 
solution, not all functionality would be subsumed. 

The author estimated RDTE funding using Robertson’s (2008) cost estimate to 
rewrite the RHS application for migration to the EDE reflected in Table 20. In the 
estimate, it was assumed that the project would take two years (26 months) to complete. 
Therefore, the estimate to complete the project of $13.1 million was divided between 
EYIO and EYll. 

Benefit Analysis 

This benefit analysis will cover both quantifiable and non-quantifiable benefits 
that could be expected to accrue to each of the focus alternatives. A full benefit analysis 
is complex and highly detailed and, therefore, beyond the scope of this research. 
Therefore, this section will attempt to capture the most applicable benefits based upon the 
available data. 

Quantifiable benefits 

Table 8 lists the types of benefits that are quantifiable. There is overlap with the 
items in this table and those listed in Table 9 (Non-quantifiable benefits) and with quality 
attributes commonly defined by IT system professionals. Eor this portion of the benefit 
analysis, focus is on the cost savings of the systems. 
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Table 8. Quantifiable Benefits 


Quantifiable Benefits 

Producti\it\' Improx-em ents 
Cost Sa\Tngs 

Improved avail ability measures showing when a s\'stem will be ddivered 
against when it is required 

Bnproved system reliability 

bnproved maintainability/supportability measures 

Bnproved flexibility and ad^tability to various modes of operations 

Bnproved accuraty, timeliness, and completeness of data produced by a 
s>'stenx resulting in efficient utilization of resources through more effective 
decisions made upon more accurate data 


Alternative 1 - $0 

The cost savings of Alternative 1 are the costs of implementing Alternative 2 
(DIMHRS) $4.5 million and Alternative 3 (EDE) $13.1 million. However, OMN costs of 
Alternative 1 are higher post-implementation than other system alternatives, as will be 
shown below. 

Alternative 2 - ($700,000) 

Alternative 2 begins accruing OMN cost savings in the year following projected 
implementation. Such savings continue through the remainder of the 10-year period 
covered in this analysis. These annual savings represent a 48% savings versus 
Alternative 1, and account for a total of $3.8 million over the 10-year period. Notice 
Alternative 2 is only $.7 million more costly than Alternative 1 ($4.5 million savings in 
Alternative 1 minus the $3.8 million Alternative 2 savings). The $.7 million dollars 
equals the difference in total costs, from table 7, of Alternative 2 minus Alternative 1 
($12,853 million - $12.115 million = $.738 million). 
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Alternative 3 - ($6,1M) 

Similar to Alternative 2, savings for this alternative come from savings in OMN 
funds. However, these savings begin in the third year for this alternative (FY12) and 
total $6.9 million over the 10-year period. However, even with these savings. Alternative 
3 is still $6.1 million more costly than Alternative 1 over the 10-year period. The $6.1 
million dollars equals the difference in total costs, from table 7, of Alternative 3 minus 
Alternative 1 ($18,259 million - $12,115 million = $6,144 million). 

Non-quantifiable Benefits 

Table 9 drawn from the EA Manual (USACEAC, 2008) includes a detailed list of 
the types of non-quantifiable benefits that are important to analyze in an EA. 


Table 9. Non-quantifiable Benefits 

Non Quantifiable Benefits 


Acceptabilin~ — does ttie alternative contribute to the operation of parallel or higher level 
organizations? Does it improve the qualitv' of the process? 

Accuracy — does the alternatir'e reduce error rates or impro\‘e the accuracy of information? 
AdaptabiKn' — is the sv'stem project adaptable to existing DoD, industry, national, or international 
standards? 

Av ailab iHrv — when can the sv’stem project be delix’ered orimplem ented: when is it needed to meet 
proposed output schedules? What is the mean time between failures? 

Compatibilitv — how will existing operations, facilities, equipment, data requirements be affected? 
How much initial training will be required? How will work methods and proceArres be altered? 

Functionalitv — how well does the sv'stem perform; how quickly can it process data or 
calciiations, or other functions? 

Maintainabilitv — is the sv'stem difficiit to repair? Are parts reaAly available? How much staff 
will be required to maintain the software hardware? \\'hat is the anticipated down time for 
maintenance? Is the maintenance downtime longer for any alternative? 

Manageabilin- — will the sv’stem project decrease the invol\-ementneed for superxisors or qualitv' 
inqsections? Will a Afferent ty-pe of persotmel than currently assigned be required? Are trained 
personnel available? 

Morale - will the sv’stem project contribute to a positive emplov'ee attitude towards work? 
Production — will the tajmber of proAicts produced be increased? 

Producrivitv — will the rate of production increase? Will the sv'stem/proj ect decrease the number 
of staff resources prexioudy needed to produce the same proAict, or will the sx’stem.'proj ect allow 
more items to be produced with existing staff resources? 

Oualitx' — xxill a better product be produced? Will better serxice be proxided? Will quality of 
products be more consistent? Is customer satisfaction improx-ed? 

Reliabilitx- — how maity' (how often) sx’stem failures will occur ox-er time? 

Security — xx-ill more or less precautions be needed? 

Service life — how long will the equipment be atie to support the operation? Will the equipment be 
obsolete before it reaches die end of its usrfil life? 

V pgradeabilitx- — hoxx- compatible xvill additional equipment, such as memoiy, terminals, 
workstations, or other eqiipm ent, be xx ith existing equipment or users of the sx'stem? 

\*ersatilitx~ — will the equipment in any altemalix'e proxide additional capacity or capability bex'ond 
that required for the sx'stem? 
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Combined with a list of quality attributes drawn from Gorton (2006), the most 
applieable attributes were distilled down to the 10 benefieial attributes used in this study. 
Benefit analysis is highly subjeetive, but, the author has built this list based upon 
applieability to the eurrent issues of the RHS system identified in Chapter II and their 
ability to position the RHS to assume the desired state deseribed in Chapter III. These 
metries are highlighted here again in Table 10. 


Table 10. Summary of Current RHS Issues and Desired Future Attributes. 


Current State Issues: 


Desired State Attributes: 

• Lack of transparency 


• Integrate with cross-functional domain 

areas 

• Excessive interfaces 


• Data, metadata management and 
semantic reconciliation 

• Non- compliance with DoD and DoN 


• Data integration across the IT 

information assurance requirements 


portfolio, including: 

• Aging hardware 


• Systems'Apps (SOA) 

• Lack of experienced technologists 


• Informatio Assurance (lA) 

• Data definition and reliability issues 


• Provide unify-able and converge-able 
content 

• Poor system documentation 


• Meet with governance: 

• Difficult to support 


• Standards 

• Cost control 

• Enterprise and strategic alignment 


After the benefit attribute list was eomplete, eaeh attribute was weighted 
aeeording to relative importanee from 1 to 5, with 5 being the most important. Then, the 
alternatives were ranked in regards to their ability to satisfy the attribute from 3 to 1. In 
this ease, a ranking of 3 meant that the alternative displayed the highest likelihood of 
addressing the desired benefieial attribute, and 1 was the least likely to display the 
attribute. The results of this ranking exereise (shown in Table 11) illustrate that 
Alternative 3 has a moderate edge over Alternative 2 and a considerable advantage over 
Alternative 1. 
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Table 11. Comparison of Benefits. 


Comparison Of Benefits 

Benefit Attribute 

Weight 
(1 to 5) 

Alternative 1 (Status 
Quo) 

Alternative 2 
(Migrate to DIMHRS) 

Alternative 3 
(Migrateto EDE) 

Rank Score 

Rank Score 

Rank Score 

Adaptability 

Availability 

Maintainability 

Manageability 

Modifiability 

Quality 

Scalability 

Security 

Serv'ice life 
Upgradeability 

5 

4 

5 

5 

4 

5 

4 

5 

3 

4 

1 5 

3 12 

1 5 

1 5 

1 4 

1 5 

1 4 

1 5 

1 3 

1 4 

2 10 

1 4 

3 15 

2 10 

2 8 

3 15 

2 8 

3 15 

3 9 

2 8 

3 15 

2 8 

3 15 

3 15 

3 12 

3 15 

3 12 

3 15 

3 9 

3 12 

Total Score 

52 

102 

128 


6. Compare alternatives. This step includes identification of mission-related 
benefits for all feasible alternatives. Benefits should be identified and analyzed in 
sufficient detail to indicate their contribution to mission accomplishment. Benefits should 
be quantified whenever possible. Non-quantifiable benefits, such as health or safety, 
should also be identified and explained in the analysis. 

In a purely quantitative aspect, Alternative 1 is the least expensive of the 
alternatives. However, this perspective does not present the whole picture. First, if we 
extrapolate the numbers out a few more years to 20 total years, our perspective is clearer. 
First, depicted in Table 12 in bold italic numbers, are the break-even points, after which, 
the alternatives are actually the less-expensive options. This happens at year 12 in the 
case of Alternative 2 (DIMHRS) and at year 16 for Alternative 3 (EDE). Although it 
may seem to be a stretch to extend the analysis to 20 years, given the track record of 
similar systems within the DoN, it is a distinct possibility that these systems would still 
be in operation that far in the future. 
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Table 12. Extended Cost Projections Showing Break-even Points 


Yre. 

FY 

AKemative 1 
(Status Ouo) 

CHIN ROTE 

Alternative 2 
(DIMHRS) 

OMN ROTE 

A Ifemative 3 (H)Q 

OMN ROTE 

1 

10 

1.033 


1.033 

1.000 

1.033 

6.543 

2 

11 

1.069 


1.069 

1.250 

1.069 

6.543 

3 

12 

1.106 


1.106 

1.250 

611 ■ 

13.0b6 

A 

13 

1.145 


1.145 

1.000 

316 


5 

14 

1.185 


611 

4.53-: 

327 


6 

15 

1.227 


632 


339 


7 

16 

1.289 


65-4 


351 


3 

17 

1.314 


677 


383 


9 

18 

1.380 


701 


376 


10 

19 

1.407 


725 


389 


11 

20 

1.457 

13572 

751 

13.604 

402 


12 

21 

1.588 

15.080 

777 

14.381 

416 


13 

22 

1.561 


804 


431 


14 

23 

1.615 


832 


446 


15 

24 

1.672 

19.927 

861 

16878 

462 

20.416 

16 

25 

1.730 

21557 

891 


478 

20.894 

17 

26 

1.791 


923 


495 


18 

27 

1.853 


95-5 


512 


19 

28 

1.918 


988 


5X 


20 

29 

1.985 


1.023 


548 

(1319) 


Given the distinct possibility that the chosen system would be in place for longer 
than the 10 years covered in this analysis, the relative strength of the non-quantitative 
analysis is strengthened. In this portion of the analysis, the strongest relative system was 
Alternative 3 (EDE). In the subjective ranking analysis, this system scored higher than 
the other two alternatives by a fairly substantial margin. 

Now that we have reviewed the costs and benefits of the three alternatives, the 
three most important advantages and disadvantages not yet covered are given 
consideration. 

Alternative 1 - 

Advantages 

• The system is currently in production (availability). 

• Costs are relatively stable and known. 

• The system has, to date, been able to perform its mission objective. 

Disadvantages 

• The system is based on very old technology. 

• It is difficult to and expensive to maintain. 

• It is not compliant with current DoD and DoN Information 
Assurance requirements. 
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Alternative 2 (DIMHRS) - 
Advantages 

• Projected costs are not much more than the current costs to run the 
RHS. 

• The system leverages state-of-the-art technology that will be used 
throughout the DoD (possesses many quality attributes). 

• The system is compliant with all DoD and DoN IT governance. 


Disadvantages 

• Program has had numerous delays, as evident from the Army 
placing it’s implementation in an on-hold status until further 
notification (poor availability). 

• Not all functionality of the current RHS will be captured 
(incomplete solution). 

• Potential mismatch of operating model to DoN needs (unification 
versus coordination). 

Alternative 3 (EDE) - 

Advantages 

• The system would be able to leverage modern technology that is 
DoD and DoN compliant in a relatively short timeframe (24 
months); it addresses multiple benefits/quality attributes, including 
availability. 

• The system captures all current functionality (less expensive to 
support than the other alternatives). 

• It has a proven track record of migrating other systems to this 
solution. 


Disadvantages 

• This system is the most expensive of the three alternatives, 
requiring considerable investment in the near future. 

• The system would incur additional costs if and when the Navy 
migrates to the DIMHRS. 

• Pilot programs that have migrated to this system were not entire 
cut-overs; therefore, unforeseen complications may arise, 
increasing expense and lengthening development time. 
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7. Report results and recommendation. Results and recommendations that are 
fully supported. 

Although Alternative 1 is the least expensive option, the reeommendation of this 
analysis would be to implement Alternative 3—the most expensive option. This is due to 
the faet that Alternative 3 offers the best ehanee to upgrade the eurrent RHS system in the 
timeliest manner. Further support for this reeommendation is based upon the following: 

• Will eover all eurrent fimetionality, 

• Meets all DoD and DoN IT govemanee, 

• The EDE has undergone proof-of-eoneept testing, and 

• Will offer eonsiderable benefits in the near future. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. PRIMARY RESEARCH QUESTION 

What are the implications of migrating from the Navy’s current disparate data 
warehousing architecture to an integrated solution with a focus on the Reserve 
Headquarters Support (RHS)? 

In the course of this research, the author has worked to answer this question. 
First, this study provided an overview of the current state of Information Technology (IT) 
systems at all levels of the Department of Defense (DoD), with a particular emphasis on 
systems that deal with personnel and their associated data. Ultimately, the research 
examined the systems, their associated architectures, and related IT guidance of the DoD 
and the Department of the Navy (DoN), and concluded with a detailed examination of the 
Reserve Headquarters Support (RHS) system. A common theme at all levels of the 
organization was that the IT environment is highly complex and built upon a technical 
architecture that is old and not well suited to effectively and efficiently operate in today’s 
environment. Initially, these systems were built to address specific business functions of 
their respective agencies, not to inter-operate with other systems within the department. 
More recently, interoperability has become critical, necessitating changes to these 
systems to address issues they were not initially intended to address. Finally, these 
factors have led to the current state of IT personnel systems, which are typified by aging 
technology, poor data quality, inefficient architectures and non-compliance with current 
information-assurance guidance. 

The current issues described are complex problems that have been recognized at 
all levels of the DoD. This recognition has leaders within their respective organizations 
expending a lot of time, energy, and effort to remedy the current issues. To date, most of 
this effort has come in the form of vast amounts of IT guidance driven from strategic 
organizational guidance. In regards to the DoD’s personnel-related IT systems, perhaps 
the most important step taken to date has been the creation of the Business 
Transformation Agency (BTA) in 2005. This organization has been charged by the 
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Secretary of Defense (SECDEF) with providing guidance and leading the development 
efforts to ensure the interoperability of all personnel systems within the department via 
the Defense Integrated Military Human Resource System (DIMHRS). Eikewise, the 
DoN leadership has recognized the same issues and has focused on developing guidance 
and strategic plans to remedy them. In particular, the MPT&E organization has created a 
vision and provided direction as to what the future of these systems should ultimately 
look like. In conjunction, the SSC NOEA team has worked to create an Enterprise Data 
Environment (EDE) that may be helpful in solving many of the problems associated with 
the current systems’ data. Finally, concerning the RHS system, the leadership has taken 
steps to transform the system into a modern IT application that is based upon open and 
interoperable technology and is also compliant with DoD and DoN information assurance 
guidance. 

Finally, in Chapter IV, the researcher introduced methods that present promise in 
their ability to transform the current state of DoD IT Systems to the described desired 
state. Throughout the DoD organization, individual agencies are at different stages of 
transformation. The important thing is that efforts are being made to create IT solutions 
that will persist into the future at all levels of the organization. Further, these solutions 
are being approached from an unprecedented level of joint operability. The implications 
of these factors for the RHS system is that to meet the goals of the DoD and the DoN, 
decision-makers must begin soon to transform the application from its current state to one 
that will meet the needs of the future force. A major impact this transition will have is 
that it will make near-real-time information accessible at all levels of the organization. In 
addition to enabling key decision-makers to make difficult personnel decisions in a 
timely manner, it will provide accurate and trustworthy data on which to base such 
decisions. For example, when a need for a logistician possessing a particular skill set at a 
forward-deployed Army depot is determined, the transformed RHS system will enable 
that need to be met by a Naval Supply Corps Reserve officer in a matter of minutes— 
versus the current scenario, in which this action can take days, weeks, or even months. 
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All of this will be accomplished using modem technology, which is easier to maintain 
than legacy systems and that has greater ability to interface seamlessly with other 
organizational systems via a service-oriented architecture. 

B, SUBSIDIARY QUESTIONS 

1. What is the cost of the current data warehouse solution; how much would 
it cost to upgrade, and what cost model can be used to appropriately forecast the cost the 
upgrade? 

In Chapter IV, a lO-year projected cost estimate for the current RHS application 
was estimated to be $12.1 million in operational support funding. Two alternatives were 
presented as potential replacement solutions. The cost of one alternative, a direct cut¬ 
over to the DIMHRS, was projected to cost $4.5 million in investment costs and $8.35 
million in 10-year maintenance costs, for a total of $12.85 million in costs. The second 
alternative, a cut-over to an enterprise data environment (EDE), was projected to cost 
$18.25 million over the same period, broken down into $5.17 million in maintenance 
costs and $13.08 million in investment costs. 

To appropriately address the question, “Which cost model will more accurately 
forecast the cost to upgrade?”, the author determined that a cost model was not robust 
enough to capture the pertinent information necessary to make this determination, as it 
would focus on a comparison of the quantifiable costs of the alternative systems. Instead, 
the researcher decided it was more appropriate to not only estimate quantifiable costs and 
benefits, but to measure non-quantifiable, qualitative benefits of the alternatives, in 
addition to an economic analysis based upon the Department of the Army’s Economic 
Analysis Model. 

2. What is the current technical architecture that supports data warehousing 
of the Navy’s data, and is it appropriate? 

In the course of this research, the author did not find any formal IT architectural 
standards that were enforced or followed within the DoN that apply its IT systems in 
general or to the RHS application specifically. The current technical architecture and 
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data structure, as applied speeifieally to personnel-related systems at all levels of the 
DoD, is one in which stand-alone applieations working in individual business-proeess- 
defined silos that meet the specific functional needs of the owning individual agencies 
prevail. The leadership within the DoD, DoN, and their assoeiated business units have 
deemed the eurrent data environment as too restrietive and isolated to be effeetive in the 
eurrent elimate of interageney eooperation and support at all levels of the organization. 

3. How would migration of the RHS be carried out from a technical 
standpoint? 

In Chapter IV, it was determined that although there is not a elear-eut answer to 
this question, proven methodologies do exist that address this issue. The works of Gorton 
(2006) and Ross, Weill and Robertson (2006) proved valuable in defining, among other 
things, the underlying theories enabling organizations to suceessfully implement an 
enterprise arehiteeture. These works helped the author to define an environment that 
would be eonducive to proeeeding with the migration. Although the actual technical 
steps of migration are beyond the seope of this researeh, the methodologies in Chapter IV 
deseribe how an organization ean inerease its chances of successfully transforming itself. 

C. FINAL THOUGHTS 

The state of the DoD and its IT systems are at a eritieal juneture in their 
lifeeyeles. For too long, individual ageneies under the Department’s prevue have been 
allowed to set their own IT standards and define their own data requirements—leading to 
an ineffieient and expensive way of eondueting business. However, at all levels of the 
DoD, leadership has begun to respond. They are fully supportive and engaged in the 
ereation of an IT environment that breaks down the barriers assoeiated with the eurrent IT 
systems. Evidence of this is seen in aetions like the ereation of the BTA in the DoD, and 
FORCEnet in the DoN. These efforts are in eoneert with the following statement made 
by Ross et al. (2006): “The best eompanies are foeused on eliminating those silos that are 
limiting business effieieney and agility” (Ross et ah, 2006, p. 88). 
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To keep this momentum, it will be neeessary to begin achieving some victories. 
From the perspective of the author, the RHS can be one of these victories. The strategy 
of starting small and having a successful implementation would go a long way towards 
moving the DoN in the right direction; the RHS would be an example of a successful 
transformation of an IT system within the DoN portfolio. Additionally, the Navy appears 
to have acted wisely in choosing a business operating model that is based upon 
coordination. It shows an understanding that its organization is at Stage One of 
enterprise architecture maturity, and the only way to proceed through the stages is to 
progress one stage at a time. Perhaps this is why the DIMHRS is having issues at the 
time of this writing, because it appears as though it is trying to go directly to Stage Three 
without going through Stage Two first. As Ross et al. warn, “for large companies each 
stage is several years” (2006, p. 85). Finally, the DoN direction appears to be in line with 
the recommendation of building an architecture capability in-house because “an ongoing 
dialogue about the relationship between IT and business process is essential for effective 
enterprise architecture” (Ross et ah, 2006, p. 89). 

D, RECOMMENDATIONS FOR FURTHER CONSIDERATION 

The recommendation to go with the EDE solution in this research was largely 
based upon the non-quantifiable benefits this system would provide. There exists vast 
potential for savings, especially in the element of time, when organizations are 
empowered and enabled with the ability to find the necessary data when it is needed and 
its accuracy is assured. Considering the benefits of time and access to the proper data, 
the author believes that an effort to quantify these savings would provide further evidence 
that this alternative would more than pay for itself in a relatively short timeframe. 
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